Permissions Definition

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).

For each user role you add a set of permissions.

   <role name="Administrator"/>
   <permissions>
      <permission resourceref="#PRJ">
         <action type="checkout">ALLOW</action>
      </permission> 
. . . . . . . . . . . . . . . . . . . . . . . . . .
   </permissions> 

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 Resource Types and Corresponding Action Types the resource types and their available action types.

By default, all permissions are denied. If a certain permission is not explicitly given to a role, then the role does not have the permission. This approach ensures unauthorized users do not accidentally gain access to restricted resources.

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.

Note that for use in TIBCO BusinessEvents Decision Manager, most TIBCO BusinessEvents project resources have only a read action type.