Scope of System Actions
The scope of a system action is defined by where in the organization model the privilege required to perform that system action is assigned:
- The default scope of a system action is system-wide. (Either any user or no user can perform the system action.)
- Privileges can be assigned to any system action at the organization model level.
- Privileges can also be assigned to some system actions at the level of the organization unit, position or group.
- A user can always perform certain actions (for example - View Work List and Set Resource Order Filter Criteria) if they are themselves the explicit scope of that action - that is, if they are not just related by position or group.
For example, the following table shows the default value and the possible scope for the system actions mentioned in the preceding section.
| System Action | Permitted for all users by default? | Assign a privilege required to perform this system action to: | |
|---|---|---|---|
| - an Organization Model? | - an Organization Unit, Position or Group? | ||
| User Admin | Yes | Yes | No |
| View Work List | No | Yes | Yes |
| Open Other Resources’ Items | No | Yes | Yes |
| Open Work Item Audit Trail | Yes | Yes | No |
If different privileges are assigned to the same system action at different levels in the organization model, each level is checked when determining whether a user has the necessary privilege to be able to perform a particular system action. If the lowest level has no required privileges assigned, the parent entity is checked, and so on up the organization model hierarchy to the default, system-wide value.
For example, in the following diagram the "View work list" system action has been associated with three different privileges, "X", "Y" and "Z", at three different level - the organization model, organization unit A, and position 2.
This means that a user must hold privilege "X", "Y" or "Z" to view the work list of a user who holds Position 2.
If a user wants to view the work list of a user who holds Position 1, they must hold privilege "X" or "Y". This is because no privilege has been associated with Position 1, so any privileges associated with the parent entity are used instead. If privilege "Y" had not been associated with Organization Unit A, the user would instead need privilege "X", defined in the parent Organization Model.
As well as assigning different privileges at different levels, as shown above, qualifiers on the same privilege can be used to refine how access to a particular system action is controlled. (When comparing a required privilege to a held privilege, if either side is not qualified the comparison is positive. If both sides are qualified, the qualifications must match for the comparison to be positive.)
Controlling access to system actions by the application of (user-defined) privileges within the organization model provides an organization with a powerful and completely flexible way to customize and tailor users’ access to system functions.