Permission inheritance

Permissions set on an entity are not isolated: they cascade to what is linked to it. Once a user’s role on a project is defined, there is no need to configure each office, supplier or person separately.

From the project down

Project role	Office role	Person role	Supplier role
Admin	Manager	Manager	Admin
Manager	Manager	Manager	Admin
User	User	User	User
NA	NA	NA	NA

From the office down

Office role	Action role	Person role
Manager	Manager	Manager
User	User	User
Guest	User	User
NA	NA	NA

And from a functional area of an office:

Action role	Person role
Manager	Manager
User	User
NA	NA

Combining levels

Permissions from different levels add up: a user can hold one role on the project and a different role on a single office.

A user with the User role on the project sees everything but changes nothing. Adding them to the Training manager group of one office gives them write access in the training area of that office alone: they see all company data and write only in their own area.

Note

Office permissions are not an alternative to project permissions: they are an extension of them. Set the general level on the project, then raise it where the person is actually responsible.

From the office–supplier association

Office role	Role on the supplier
Office manager	Supplier admin
Office guest	Supplier user

And in the opposite direction:

Supplier role	Role on the office
Supplier user	Office guest
Supplier user	Office procedures user