System Actions and Organization Model Versions
The assignment of privileges to system actions may change between versions of the organization model.
Changes made within the same major version—for instance, between versions 2.0, 2.1, and 2.2.1—are merged for the purposes of checking required privileges. Changes between different major versions are more complex. See "Security" in TIBCO ActiveMatrix BPM - BPM Concepts for details.
Viewing Supervised Work Lists
The primary use of the scoped system actions are for controlling the ability to view supervised work lists. A few of the other system actions available at the organizational entity-level control access to functions from a supervised work list.
This section describes what is necessary to set up system actions to be able to view a supervised work list.
When a supervised work list is requested with the getWorkListItems operation, you can request that it contain either:
- Work items sent to an organizational entity - This type of supervised work list only contains work items that were sent directly to the specified organizational entity.
To be able to get this type of supervised work list:
- A privilege must be assigned to the BRM.viewWorkList system action for the group, organization unit, or position for which you want to supervise, and
- you must possess the privilege (and possible qualifier) assigned to the scoped BRM.viewWorkList system action for the organizational entity you want to supervise (you gain the privilege by being mapped to a group or position that gives you that privilege).
In the following example, the Claims Handling organization unit’s scoped "View Work List" system action has a privilege assigned:
In this example, a logged-in user who possesses the "Manage Work" privilege, can view a supervised work list for the Claims Handling organization unit.
Note - The checking for needed system actions is hierarchical—for more information, see System Action Hierarchy.
- Work items for an individual resource - This type of supervised work list contains all of the work items that are currently in that resource’s work list.
To be able to view this type of supervised work list:
- A privilege must be assigned to the BRM.viewWorkList system action for a specific position to which the desired resource is mapped,
- you must possess the privilege (and possible qualifier) assigned to the scoped BRM.viewWorkList system action for the position (you gain the privilege by being mapped to a group or position that gives you that privilege).
In the following example, a privilege has been assigned to the "View Work List" (BRM.viewWorkList) scoped system action on the Claims Handler position:
This allows a user who has the "Manage Work" privilege, with a qualifier of "Claims", to get a supervised work list for a user who has been mapped to the Claims Handler position.
Note - The checking for needed system actions is hierarchical—for more information, see System Action Hierarchy.
System Action Hierarchy
The checking of system actions is hierarchical.
If different privileges are assigned to the same system action (e.g., BRM.viewWorkList) 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 system-wide, organization model-level 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 levels—the organization model, organization unit A, and position 2.
This means that a user who holds privilege "X", "Y" or "Z" can view a supervised work list:
- for either Position 2 or Organization Unit A, or
- for individual resources that have been mapped to 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.)
For more information about system actions, see the BPM Concepts guide.