Understanding Direct Permissions

Security on EPC objects has evolved to direct permissions. This means that System Admins can now define different security permissions per object at any level. Security can be set by group, role or user at any level (environment, set, folder, object) and still have the option to “apply to all children” with one click.

Security will automatically be inherited from the direct parent folder or object when a new object is created. This way there is no manual effort required to apply security on newly created objects, however, offers the flexibility to be adapted at any level

Why is direct security preferable?

Direct permissions are useful to control access to specific sensitive information (e.g. Documents) no matter where they reside in the hierarchy. Access rights are a lot simpler for ongoing monitoring and management because you can view in the tool exactly who and what level of access is given per object. Additionally, direct security improves system performance since it no longer has to compute access permissions at run-time.

Permission Levels

  • Read published: users will be able to see only the published version of the object and won’t see “in progress” (draft) versions. Additionally, they won’t be able to edit or delete the object.
  • Read latest: users will be able to see all versions of the object but won’t be able to edit or delete it.
  • Write: users will have access to all versions of the object as well as editing rights but won’t be able to delete the object.
  • Delete: users will have access to all versions of the object. They can also edit and delete. Modelers with this permission can set object security.
  • Environment Admin: users will be administrators in the chosen environment. They will have Delete permission on all objects in the environment as well as being able to access the environment admin section and set security permissions on objects.
See published versions See all versions, drafts Can edit the object Can delete the object Can set security perm. Access to Env. Admin Section
Read published X
Read latest X X
Write X X X
Delete X X X X If Modeler, yes
Env. Admin X X X X X X

As an example, you could assign the “delete” permission on a set to a group, but only grant them “read latest” on a more delicate folder within that set, ensuring that nobody in the group will be able to edit or delete. This new way of assigning security allows to set independent and micro-settings of security. More information about the rules of this feature can be found in our user manual.

On the other hand, if your security needs are simpler, it is possible to set these permissions at the environment level. This way, you can assign permissions at once, for all objects in the environment.

“What do I need to do?”

“Legacy Inherited Security” will be automatically converted and migrated to direct permissions during upgrade, however, it is important to:

  • Validate your pre- & post- upgrade security permissions.
  • Note that there is no longer “deny access permission” since deny is implicit by removing the user or group that was previously denied on direct permissions. Setup a call with the account manager or consultant working on your project to best understand impacts on complex security setups.

Need more help with this?
Don’t hesitate to contact us here.

Thanks for your feedback.