Direct and indirect access

A user obtains permissions in two ways. Telling them apart is what lets you answer the question “why does this person see this?”.

Direct access

The user is explicitly assigned to a group of an entity — a project, an office, a person, a supplier. It is a manual assignment, and it grants the permissions of that group on that entity and on everything directly linked to it.

Example

A user added to the manager group of a project has direct access to that project.

Indirect access

The user was never assigned to that entity, but reaches it through a relation. Think of it as a network: the user is assigned to a “child” entity, the child belongs to a “parent”, and the user therefore reaches the parent too — indirectly.

Example

A user added to a group of an office also appears in the users list of the project that office belongs to. They have direct access to the office, and indirect access to the project.

Why this matters in practice

The Users sub-menu of an entity lists only who has direct access to it. Someone can therefore operate on a project without appearing in its list — because their access comes from an office, a person or a supplier below it.

When a user sees more than you expect, look down, not up: the permission usually comes from an entity further along the chain. The propagation rules are in Permission inheritance.