Access Precedence

A person's access depends on their role, credentials, policies, and rules. These items could grant or deny access. The flow chart shows how the system determines if a person has access to an object or action.

Suppose a person definition does not include delete access, but a policy assigns delete access to the user. Will the user be able to delete an object governed by the policy? The answer is no; the user won’t be able to perform the action because the person definition takes precedence over the policy.

The highest level of access control occurs through the user interface: users who have delete access for an object can only delete the object if the user interface provides some mechanism, such as a Delete link, button, or menu option, that lets users delete the object. If the application is built using configurable components (such as command, menu, table, form objects), you can use access features for these components to control who can see these user interface elements. The access features include restricting user interface components to specific roles or access privileges. Some components also let you control access using a select expression or JPO. For information on the access controls available for configurable components, see the Legacy ENOVIA Web Apps Customization Guide.

When you attempt to perform an action for a business object, the system checks to see what type of user is defined in the person definition. If you are a System Administrator-type user, the system allows the action and performs no further checking. If the user is Trusted and the action involves read access only, the action is permitted.

If you are not System Administrator or Trusted (or if you are Trusted and the action involves more than read access), the app checks your person definition. A person definition takes precedence over accesses granted in the policy definition—if an access is denied in the person definition, you will not have that access, even if a policy assigns the access. However, you can be “granted” access to a business object even if the action is denied in the person definition. (See Access that is Granted.)

If the person definition allows access, the app next examines the current state of the policy to see if you are allowed access. The policy allows the user access if the access for the action is assigned to one of these categories:

  • public
  • owner and the user is the owner
  • user or to a user category (group, role, association) to which the user belongs
  • key that evaluates the user

If the user is denied access in the policy or person definition, the system checks to see if the user has been granted the access for the business object by another user. If so, the system makes sure the grantor has the access by going through the same access checking as described above. If the grantor has access, then the user is allowed to perform the action. If the user has not been granted access or the grantor does not have the access, the action is denied.

If the policy and person definition allow the access or if the user has been granted access, the user is allowed to perform the action with one important exception. If the action involves an attribute, relationship, form, or program, the system first checks to see if any rules deny access. If the system finds a rule that governs the attribute, relationship, form, or program for which the action applies, it goes through the same kind of checking as it did for the policy. If the access is assigned for the user in any access (public, owner, or user), the action is allowed. If access is not specifically assigned in a rule that governs the object, access is denied.

Where access is found is not as important as if access is found. For example, you might receive access by virtue of belonging to a group that is assigned to a parent group that is assigned access in a policy. Your group might be denied access but the user’s role is allowed access. In addition, you might have read access to a business object, allowing attributes or a form to be displayed, but then have modify access to an attribute denied.