Enovia MatrixOne Access Control

Person

--creator

--guest

--[user]

Use the user categories in policies and rules to control user access.

Business objects are governed by a policy. The policy defines who has access and when.

Groups, roles, and associations can be used in many ways to identify a set of users.

 

Access Clause

add person George access all, notoverride;

access all, notchangeowner, notcheckout, notdisconnect, notdelete, notdemote, notdisable, notenable, notoverride, notschedule;

add person George type business access all, notoverride admin type attribute policy;

 

Group(Person set) and Role

Groups are frequently hierarchical. In hierarchical groups, access privileges that are available to a higher group (parent group) are available to all of the groups below it (subgroups or child groups).

 

Roles are often similarly hierarchical. For example, the Assembly Manager role is the parent of the Apprentices and Master Assembler roles. The Master Assembler role is also a parent of the Component Assembler and Subassembly Assembler roles.

 

A child group or role can have more than one parent. Child groups/roles with more than one parent inherit privileges from each of the parents. You can establish group and role hierarchy using the procedures in this chapter.

 

Association(Group and Role set)

If users from a combination of different groups and roles will need access to a business object or set of objects, you should create an association.

Uses for Associations: Signature Definitions or Notify

 

Role-Based Visuals

Visuals (Filters, Tips, Cues, Toolsets, Tables, Views) are generally defined by users for their own personal use. They serve to set up a user’s workspace in a way that is comfortable and convenient. Visuals can be used for many purposes, including organizing, prioritizing tasks, providing reminders, or streamlining access to information. Each user can define Visuals in a way that is most helpful to that person.

 

Policy

A policy controls many aspects of the objects it governs, including who may access the objects and what tasks they can perform for each state defined in the policy. There are three general categories used to define who may access objects in each state. For each category, you may assign full, limited, or no access.

public

owner

user

 

Access Filters

User access lists defined on a policy or rule can accept a filter expression in order to grant or deny access to a specific user. For example, the access portion of the policy or rule might be:

user Writer read,modify,fromconnect,toconnect filter ACCESS_FILTER;

If the filter expression evaluates to “true,” the specified access will be granted; otherwise the access is denied.

 

Granting Access

Any person can grant accesses on an object to any other user as long as the person has “grant” access. The grantor is allowed to delegate all or a subset of his/her accesses on the current state.

 

Rule

Use rules to limit user access to attributes, forms, programs, and relationships.

For example, a policy might allow all users in the Engineering group to modify the properties of Design Specification objects when the objects are in the Planning state. But you could create a rule to prevent those users from changing a particular attribute of Design Specifications, such as the Due Date. In such a case, Engineering group users would be unable to modify the Due Date attribute, no matter what type of object the attribute is attached to.

modify attribute ATTRIBUTENAME add rule RULE_NAME;

modify form FORMNAME add rule RULE_NAME;

modify program PROGNAME add rule RULE_NAME;

modify relationship RELNAME add rule RULE_NAME;