Privilege Rules

Privilege rules are maintained in System Setup within the Users & Groups node on individual Groups.

Privilege rules are rules that specify a set of permitted actions that members of a specific group can perform on a specified set of data. There is no limit to the number of privilege rules that can be applied to the same group.

Each privilege rule is defined by specifying:

  • A group (of users)
  • An action set
  • A structure node (products, classifications, collections, publications, entities, or eCatalogs)
  • A workflow state
  • An attribute group (or one attribute).
  • An object type
  • Limitations to certain dimensions

Each group must be assigned privilege rules, defining which actions the members of that group are allowed to perform, and which data the members of the group is allowed to work with. Defining the privilege rules forms one part of the privilege control system settings. The second part, defining action sets, is performed in System Setup under Action Sets. For more information, refer to Action Sets topic here. A privilege rule grants all of the users in a group the permission to perform any of the actions in the selected action set. This permission can be restricted to specific sets of data. To prevent a group of users from making changes, refer to the Read-Only Access section below.

Important: Except for supplier privileges, privilege inheritance is not recommended since it does not allow for re-engineering when business conditions change.

Recommendations for Privilege Rules

  • Create users specifically for inbound and outbound integrations, and then apply privileges to these users. Doing this enables control of users viewing the integrations and allows for limiting of what can be exported. This is also helpful for audit trails.

  • Privilege Rules applied a User Group will be inherited to sub User Groups. This means it is possible to apply general Privilege Rules on a top level and only specify local Privilege Rules on sub User Groups. It is recommended to apply all general Privilege Rules as high as possible in the User Groups hierarchy to simplify management of the Privilege Rules.

  • Configuring privilege rules in STEPXML can save time. To do so, configure a few privilege rules in workbench, then export only the user definitions to STEPXML to use as a template.

  • Do not use Web UI configurations to limit actions as this is not sufficient for a security audit. Instead, use action sets and privilege rules to limit actions.

Privilege Rule Types

There are two types of Privilege rules:

Setup Privileges: These are usually actions that are usually performed by a System administrator.

User Privileges: For actions that should be performed by the users of a specific group.

Restricting Actions

Actions can be restricted to:

  • Objects that are linked to a specific node (or a node below) in the classification, product, publication, entity, or eCatalog hierarchy, in a specific node collection, or in a STEP Workflow in a specific state.
  • Attributes within a specified attribute group (e.g., changing an attribute value). If an attribute group(s) is not specified, the action is permitted for all attributes.
  • Workflows, integration endpoints, and business rules within a specified setup group.
  • Specified dimension points. If no dimension point is specified for a dimension, the action is permitted for all dimension points within that dimension.
  • Specified object type. If no object type is specified, the action is permitted for all object types.

Unlimited Number of Privilege Rules

Any number of rules may be set up for the same group, granting permissions for specific actions sets on a number of hierarchy nodes and dimension points.

Note: A user may be a member of multiple groups. The user will accumulate the privilege rules from all these groups, so a restriction from one group is ignored if the corresponding action is permitted via another group membership.

Editing Linked Objects

If a privilege rule permits the editing of a specific attribute value for products linked to a specific classification node, this attribute value can also be edited through other classification nodes that these products may be linked to.

Access to Classifications and Products

If a group has permission to work with a specific classification node, attribute values can be edited for all products linked to (or below) that node. However, access to the classification node does not grant the privilege to link new products in the product hierarchy. To do that, the group must have permission to work with the specific product node as well.

Read-Only Access

To prevent a group of users from making changes, create a group with the following privilege rules settings:

  • Only 'View actions' rights are added
  • The 'Read Only' checkbox is checked

For example:

This example group provides the users with only view access; the group members are not able to make any changes while logged into the system.