| Hello,
We also have a similar situation at a large customer site where
we have lots of people using DECmcc, but they should only be able
to change their part of the configuration and be able to read/monitor
all other parts. Here is, in a general context, how we solved the problem.
(By the way we run on VMS and use DNS)
We did this in two ways:
The first part is to restrict the DNS access to read and test only.
We removed from DNS the Access entry *::*, so that world privileges
were disabled. We then created groups, each group containing the
a group of users who should have the same access. We then granted
each group corresponding DNS access:
READ WRITE DELETE TEST For those objects that group can
delete, change, etc.
READ TEST For those objects he only can
look at. (this restricts the
person from deleting with the
toolbox, or adding an object to
the domain, or opening certain
domains.)
The access has to be setup up on all DNS directories and objects.
For us the problem was even more complicated, in that we couldn't
use the propagate flag, because many DNS directories contained objects
controlled by two different groups. So when we register a entity we
have to add by hand the corresponding DNS access. ( of course the
customer has since automated this via command files)
If you have only two types of users, people who can delete, register
etc, and people who can only monitor, this is actually quite simple.
You just grant the group read and test access with default propagate
to all directories, and as you register entities, the group has read
access only automatically.( Don't forget they have to have access to
the DNS directory itself also, so two ACCESS entries are required for
each group in the directory DNS$ACS attribute.)
Also this only works as long as your DNS name space is new!! If you have an
existing DNS namespace, then you will have to remove the *::* access
from each object by hand, assuming that you used the default DNS
setup provided by DECmcc.
The second level of this plan, is to restrict who can save a map file.
If you remove the write access to the map file, if they change the map
file ( as in accidentally or purposely move the icons around ) they
can't save the changes. Of course implementing only this level does not
guarantee that they can't delete the entities with the toolbox.
As far as I know, there is no way to disable the toolbox. Really too
bad, because this would be the simplest solution. I am hoping that
in a future DECmcc release "roles" will be introduced to do exactly
what I have tricked with DNS easily.
I hope this helps.
I realize this is just a general description of what we did. If you
need further details or help, send me a mail.
Julie Ann
|
| In V1.3 of DECmcc, the user will have the ability to lock any map window.
There is a lock icon in the menu bar and also a Lock/Unlock menu item in the
Map Window Edit menu.
When a Map window is locked, entities cannot be added or deleted, but the user
can still navigate and scroll.
Hope this helps.
Verna
|
| Until DECmcc integrates the concept of user roles, you can artificially
restrict some users to a certain subset of directives, for example -
SHOW. As mentioned in previous replies to the base note, you cannot,
from within DECmcc V1.2 restrict a user to management of a certain set
of entities. To restrict the update of the map or the management of
certain entities use the workarounds mentioned in previous replies.
You can achieve the restriction of directives by having more than one
dictionary on the system and pointing the user to the particular
dictionary appropriate to his/her role. Some of our customers have done
this very successfully.
To be more specific...
1) Make a copy of your mcc dictionary in some other directory.
2) Using DAP, delete, from each class, the directives you want
to make unavailable
3) When you exit from DAP, the parse tables will be rebuilt
4) Redefine your users' MCC_SYSTEM logical name (VMS) or the
MCC_SYS_LOCATION environmental variable (ULTRIX) to be a
search list that looks in the directory with the new
dictionary and parse tables first and then MCC_SPECIFIC and
MCC_COMMON (VMS) or /usr/mcc/mcc_system (ULTRIX)
Good Luck!
...kjn
|