About Organization and Project-Based Access

In policy and rule definitions, you can specify whether organization and/or project should be matched against the credentials of the user, and whether ascendants and descendants should also be checked.

For example, the following access definition filters content based on both the organization and project ownership: 

policy "VPLM_SMB"
    state "WAITAPP"
        user "VPLMCreator" read,show,changeowner,checkout,toconnect,todisconnect
            filter "(organization.ancestor match context.user.assignment[$CHECKEDUSER].org) &&
               (project ==	context.user.assignment [$CHECKEDUSER].project)"

The filter checks whether the organization of the object (organization) or that of its parent (organization.ancestor) matches the organization component of the security component granting the access definition (context.user.assignment[$CHECKEDUSER].org. For example, Company Name if the user is assigned context VPLMDesign.Company Name.Engineering).

The filter also checks whether the project of the object (project) matches the collaborative space component of the credentials granting the access definition (context.user.assignment[$CHECKEDUSER].project. For example, Engineering if the user is assigned context VPLMDesign.Company Name.Engineering).

In most cases, filters can be replaced with matching options to simplify the syntax. For the owner or public users, you might still need to use the [filter EXPRESSION].

Organization and collaborative space (project) filtering is the main recurring pattern in most access definitions. When defining or modifying a policy, you include a STATE_ITEM or STATE_MOD_ITEM as part of the access definition. For a rule, you include a USER_ITEM. These items provide matching filters for the organization or collaborative space. For more information, see State Clause for the Add Policy Command or rule Command.

MQL allows you to specify organization and collaborative space (project) access in commands that have a State clause, such as Modify Businessobject and Add Policy. This table lists the supported organization and project matching options:

Matching Option Description
any org The value of organization is not checked.
single org The object organization must exactly match the organization of the credentials granting the access.

The value of organization must match the login role or assigned credentials.

ancestor org The object organization must be an ancestor (parent organization) of the organization of the credentials granting access.

The ancestor of organization must match the login role or assigned credentials.
descendant org The object organization must be a descendant (child organization) of the organization of the credentials granting the access.
any project The value of project is not checked.
single project The object project must exactly match the project of the credentials granting the access.

The value of project must match login role or assigned credentials

ancestor project The object project must be an ancestor (parent object) of the project of the credentials granting the access.

The ancestor of project must match login role or assigned credentials.

descendant project The object project must be a descendant (child project) of the project of the credentials granting the access.

Taking advantage of the matching options, the access definition is implemented as follows: 

policy "VPLM_SMB"
     state "WAITAPP"
          user "VPLMCreator" read,show,changeowner,checkout,toconnect,todisconnect
             descendant org single project

The filter expression: 

organization.ancestor match context.user.assignment [$CHECKERUSER].org

has been replaced with the option descendant org to specify that the organization of the object must match the organization of the credentials (org) or any of its descendants (descendant).

Similarly, the filter expression: 

project == context.user.assignment[$CHECKEDUSER].project

has been replaced with the option single project to specify that the collaborative space of the object must exactly match that of the credentials.

Ultimately, all of the contents of the filter expression of the original access definition are defined using the new options, so the new access definition has no filter at all.

You can also use these keywords when defining access:

Keyword Description
login Used in place of user to represent an ACCESS_ITEM associated with the user's login role, as opposed to their assignment list.
key Used to distinguish between multiple ACCESS_ITEMs with the same USER_NAME (such as owner or public).