How to set up Operator Stations to respectively supervision and control
I have 4 operator stations. Only one of them should be able to control a part of the system, while the three others only have supervision rights.
I have found solutions to do these restictions with users, but not with operator stations.
Do anybody know how to set up operator stations, so they have supervision rights to some parts of the system, and control rights to some other parts of the system?
I asked about this question yesterday, and there was the answer to try Security Definition aspect under Domain in the Admin structure, but as far i can see, the Security Definition aspect under Domain object in the Admin structure only works, when you restrict certain users or nodes only to have for example operator rights.
In this case, one of the operator stations should have the control or operate rights to one part of the functional structure, while the other operator stations only have supervision rights to that part of the functional structure, and control rights of the rest of the functional structure.
Voted best answer
This is not a big task to perform.
1. As a member of the Administrators group in 800xA User Structure, you effectively bypass security (no risk of locking yourself out).
2. To avoid having to block users by implementing "Deny" here and there, I sincerely recommend removing the global "Operate" permission setting from the default security setting in the Admin Structure.
3. As required, add new Security Definition aspects on common "root" objects in the Functional Structure, etc. from where operators shall have operate permission. Use the "Node" feature to define if the permission shall be effective on a particular node (default is All Nodes) or node group.
4. Newly added, or copied Security Definition aspects have Authority Range = NONE as a safety precaution. Hence, after creating a new SD, or copying one, you must enable it by changing NONE to either Object or Structure.
5. Let "Everyone" have Read permission, i.e. any valid user can read any property. Why deny read when its easier to just remove such user from the User Structure?
6. The Structure Search order as defined on the Admin Structure's default security permission order may play a vital role if an object is inserted into more than one structure.
7. Removing the "global operate" permission as in step 2, requires you to add "operate" on all locations where operators need access. If an object is not "covered" by such allow definition, it will be inoperable for all (but you as an administrator).
8. If no permission is found => deny
1. normally You don't manipulate Security definition aspect in admin structure. You should create new ones in functional structure. and those security definitions will work in that tree. (try 3BSE037410-510_D_en_System_800xA_5.1_Administration_and_Security.pdf)
2. Why createing new topic when You could continue the one created yesterday?