Working with Sub-Role Privileges
Note
Sub-role privileges are one of the Account Management features introduced in Rubicon host applications in 2017. They appear in DMS version 4.0 and SCADAConnect Forms version 2.0 and later.
Sub-Role privileges are used to control what changes you can make to other user accounts based on your role and the role of the other user.
How do sub-role privileges work?
The ability to apply a change to another user account is controlled by granting the privilege to make that change. A privilege is granted to a role, and applies to another role called a sub-role. Restrictions based on sub-role privileges are ignored if privilege checking is disabled for the sub-role.
Example
You can grant the PLANNER role the Reset password privilege over the OWNER sub-role. This means that planners can change the password of any owner.
Sub-role privilegechecking for changing party details is disabled by default
Sub-role privileges only apply to a role if a Privilege check for the privilege is enabled for the role. This has two advantages:
- You can implement the new functionality gradually by enabling it for specific roles.
- You can exclude a role from the privilege check. For example, you might do this for secondary roles that users might hold in addition to their primary roles.
Privilege checking is enabled on the Details tab of the Roles module.
Note
The Grant Authority privilege check cannot be disabled. This is to retain compatibility with previous versions of the applications.
What happens if a user has more than one role?
If a user has more than one role for which privilege checking is enabled, you must have appropriate privileges over ALL of those roles in order to make changes to their account. If you are having trouble changing a user account, check the user's roles on the Parties > Authority tab.
Note
This applies only to directly held roles, not sub-roles. Directly held roles are those displayed on the Parties > Authority tab for a user.
What privileges can be configured?
These are the privileges that can be configured for a role and sub-role.
| Privilege | Description |
|---|---|
| All access | Includes all the other listed privileges for the sub-role. When you choose this option the other privileges are all added individually. |
| Delete party | Delete a party record |
| Edit user accounts |
Edit details on the user's Accounts tab. For example, add an authentication group to the party or disable account access. It does not include the ability to reset a password. |
| Edit user customer no. | Edit the Customer Number. |
| Edit user details | Edit user details other than those controlled by other privileges. |
| Edit user email address | Edit the user's email address. |
| Edit user mobile no | Edit the user's mobile phone number |
| Edit user name | Edit the user's name |
| Grant authority |
Grant authorities to the user. For example, assign a role to a party to log into a system. Note that once you have granted an authority to a user, your ability to make further changes to their account will depend on your privilege settings. You may find that some sub-roles have this privilege applied to preserve any legacy sub-role relationships that pre-date the changes to account management. |
| Reset password | Reset the user's password. |