Access control settings are created using XML files with the extension .ac. You can create or modify an
RMSProjectName.ac file using any XML editor. This section explains the elements used to define access control, ways you can add or edit access control files, and where to place the files so they can be used by the RMS, Decision Manager components, and TIBCO BusinessEvents WebStudio.
In the resources element, you group the project resources in whatever way supports the permissions you want to set. You give each grouping or individual resource an ID that is used when defining the permissions.
How you specify the resource group is partly determined by the resource type attribute. The resource type can act as a filter. For example, suppose in the
name attribute you specify a directory that includes events and concepts. If you set the
type attribute to
"CONCEPT" then the ID associated with this grouping is used to set permissions only on the concepts in that folder (and its subdirectories).
You could create a second grouping whose type specifies
"EVENT" so that you can set permissions on events in that folder branch separately.
To specify an individual resource, provide the project path to the resource in the
name attribute. The project path is the folder path to the ontology entity, as seen in the Explorer panel. The example below shows how to specify an ID that is associated with the
FirstName property of the
Person concept:
See Table 34, Resource Types and Their Allowable Action Types for a list of resource types, and the action types that are valid for each resource type.
As explained in Specifying and Grouping Project Resources, you define a list of resource IDs according to the way you want to group resources and actions. All items included under one resource ID must be of the same resource type (or type of activity, such as checking out a project).
Each resourceref points to a resource ID. You create permissions using the actions available for the resource type specified for that ID, such as
create,
read, and
modify. See
Table 34, Resource Types and Their Allowable Action Types for the resource types and their available action types.
Permissions are not hierarchical. That is, a create permission does not imply a
modify permission or a
read permission. All privileges are mutually exclusive. So, for example, if you want users to be able to modify some resources of a certain resource type, be sure to also give users the ability to view that resource type.