Creating Roles and Policies

If you must abandon the baseline behavior, implement new security rules and potentially new business rules. You can:

  • Create roles using the P&O Import tool.
  • Create policies using MQL : it is possible to copy an existing one. Customer will have to replace all policies even if he needs only to modify one. Policies are targeting the object types.
  • Connect the policies to all object types.

This page discusses:

Create a Role

The following script is a P&O Import file that lets you create a role that extends the existing baseline Owner (VPLMCreator) role:

*VERSION 419
*SEPARATOR ;
*NULL $
 
*ROLE VPLMCreatorCusto;VPLMCreator;Custom creator role
Important: Internal inheritance for 3DSpace baseline behavior access roles (for example. Leader VPLMProjectLeader or Author VPLMCreator) may change over releases. Upgrading will not fail however, you may have to reconsider access role permissions due to inheritance changes.

The following script is a P&O Import file that lets you create a role from scratch.

*VERSION 419
*SEPARATOR ;
*NULL $
 
*ROLE Custom Engineer;$;Custom engineer role

Create Policies

A policy is an administrative object that can be created in MQL. It applies to one or several types and contains basically two types of information that are intertwined:

  • A maturity graph which is a set of states and transition between these states.
  • Privileges to access and make operations on data of these types, based on the following parameters:
    • The business role of the connected user
    • The current maturity state of the data
    • Rules related to the ownership of the data (am I the owner, or no rule regarding ownership)
    • Rules related to the compatibility between the organization that created the data and the user's organization (strict equality, ascendant or descendant inheritance)
    • Rules related to the compatibility between the collaborative space where the data has been created and the collaborative space on which the user is logged (strict equality, ascendant or descendant inheritance).
Important: You can also declare more complex privileges based on some attribute values of the data. In this case, the security cannot be indexed anymore.

Connect Policies

For objects created on the rich client side, connecting policies consists in creating business rules that return the name of this policy, and then in associating the business rules for each object type using Data Setup or the business rules web editor.

Notes:
  • Business rules must be associated to the Corporate collaborative space, which means that they will always be invoked.
  • It is difficult to assign business rules to all types defined in the baseline solution because if you want to override a business rule, you must define a new one for the same type.
  • As an example, you can have a look at the baseline business rules that are stored as CATRule files and CATRuleExit files in the server side runtime view under resources\knowledge\script.
  • The business rules used to choose the policy use the INFRAAuthorizedPolicies opening ID. To find all types that have an out of the box associated business rules, you can search for INFRAAuthorizedPolicies in CATRuleExit files.

Below is the content of the ENOAP_PRODUCTCFG.CATRuleExit: 

</Script><Script OpeningID="INFRAAuthorizedPolicies" Type="VPMReference" ScriptName="ENOAP_PolicyChooser_Definition" />
<Script OpeningID="INFRAAuthorizedPolicies" Type="VPMRepReference" ScriptName="ENOAP_PolicyChooser_Definition" />
<Script OpeningID="INFRAAuthorizedPolicies" Type="VPMPort" ScriptName="ENOAP_PolicyChooser_PORT_Definition" />
<Script OpeningID="INFRAAuthorizedPolicies" Type="VPMConnection" ScriptName="ENOAP_PolicyChooser_CX_Definition" />
</Scripts>

If you assign different policies to these object types, create business rules in Data Setup and associate them to the different types.

For web apps (that do not rely on this business rule mechanism for policy choice), you must modify the business logic of the concerned web app to assign the policy.