Granting the Required Privileges Through an Organization Model
The User Access sample application includes a sample organization model, AccessSample.om, that defines the privileges and groups used in the sample application.
Unless you deploy an organization model that grants the privileges referenced in the userAccess.xml file included in this sample application (such as AccessSample.om), only the tibco-admin user (or other System Administrators) will be able to do anything in the sample application.
AccessSample.om can co-exist with other organization models, so you can deploy it onto a test system that already has an organization model and processes, or you might choose to implement something into your own test organization model that is similar.
AccessSample.om includes the following groups:
Each group is named for the privilege that it grants.
Note that several of the groups are nested underneath the Minimal WorkList Users group (which provides access to the work list itself, via the MinimalWorkList user access set in the userAccess.xml file). This is done because it would not make sense to grant the privilege associated for the subordinate without granting the privilege for the parent group. If the user cannot view a work list, it would not make sense to give them the ability to view individual custom menu items and toolbar buttons under that list, or to grant a few advanced work list-related functions. Privileges are inherited from parent groups, so if you make a person a member of Advanced WorkList Users, they will be granted both the MinimalWorkList and AdvancedWorkList privileges.
If you deploy the sample organization model (or incorporate something like it on your own) and run the sample application as tibco-admin, you can then add resources to the various groups.
When you log in as someone who is only a member of Minimal WorkList Users they will only be able to work with work views and work lists; some functions (those only granted through AdvancedWorkList) will not be available.
For a user that is a member of one or more of the Start*BusinessServices groups, the appropriate custom menu items and toolbar buttons are displayed.
The “filtered” list of business services includes those that include an “a” somewhere in the process name, and the “remaining” list is those that do not include the letter “a” in the process name.
Note that filtering business services on the process name containing an “a” is obviously not a realistic business case. It is used in the sample application merely as an example. It is expected that you would modify the following files to tie access to a more realistic business case.
.../wccAccessSample/application/prototypes/CustomWorkListToolbar.xml .../wccAccessSample/application/prototypes/mnuCustomWorkListServices.xml
Also refer to the comments in the customStartBusinessService function in the following file for more information about how the sample application controls filtering:
.../wccAccessSample/application/js/AppMain.js