Roles & Permissions

Permissions in Primentra are always granted through roles. There are no per-user permissions. To know what a user can do, look at their roles.

Watch the whole thing in 6:09 — a role built from nothing, one tick on a model reaching three entities, Moderator on one entity, three columns with a setting of their own, and the role saved and given to a user:

Roles live in Settings › Access Management › Roles.

Step 2 of the role page: the legend, a model, its entities and the columns of one entity, each box solid when set here and dashed when it follows the model(click to enlarge)

Create a role

1. Click New above the list of roles.
2. Under Settings, enter a Role name and an optional Description.
3. Choose a Role type if the role needs one (see below).
4. Click Create role.

The role page then shows numbered steps:

1. Settings: the name, the description and the role type. This step has its own Save.
2. What this role may do: the permissions. This step has its own Save permissions. See The permission list.
3. Who gets this role: click Add user and pick a person. Each change here saves at once, without a Save button.

Members from Active Directory

When Active Directory sign-in is on, an AD group can grant a role. You add the group on the role page, in the step Who gets this role. The step Has the role now lists every person with the role and the reason: Through AD group and the name of the group, or added by hand. See Active Directory & SSO.

• You cannot remove by hand a person who has the role through an AD group. The person loses the role when they leave the group.
• Users that you add by hand stay, and the sync never touches them. With Add user you can also pick an AD account that is not in Primentra yet: Primentra creates a user linked to that account.
• When you add an AD group, the linked people in that group get the role at once. A person who is not in Primentra yet gets it at the first sign-in.
• When you remove an AD group, the linked people lose the role at once. A person who loses the administrator role this way is also signed out at once, so an open session cannot keep administrator rights.
• When you delete a role, its AD groups go with it. The confirmation names the groups, and the people in them lose the role at once.

Role type

Two checkboxes under Settings change what the role means.

• Administrator — members get full access to everything and bypass every permission check. The permission matrix is ignored for them.
• Approver — members can approve changes. Only users in an Approver role can be assigned as approvers on an entity.

An Administrator role shows an amber banner in step 2: Administrator role — permissions do not apply.

Permission scopes

Permissions cascade through three levels.

The permission list

Step 2 of the role page, What this role may do, shows one list: each model, its entities below it, and their columns below them. Every model starts closed. Click the arrow before a name to open it, or click Expand all at the top right. A closed model says what it holds, for example 5 entities · model: Read · 1 entity with its own setting.

Each box tells you where its right comes from:

The legend above the list shows these marks. Point at a box to read where its right comes from, for example Read: follows the model Sales.

Click a box on an entity that follows its model, and the entity gets its own setting. It starts from the rights of the model, plus your change. From then on, a change on the model no longer reaches that entity. Click the × of its own setting to make it follow the model again. A message with Undo stays for 10 seconds.

An own setting replaces all rights of the model for that entity, Moderator too. When the model has Moderator and the entity has its own setting without it, the row says Moderator on the model does not apply here.

Find a model, entity or column filters the list by name. Only own settings shows only what differs from the level above. Every model stays in the list; a model with nothing below it that differs says nothing differs.

The column header and the model you are in stay at the top while you scroll. While you have unsaved changes, the bar with the number of changes, Cancel and Save permissions stays at the bottom of the window. Save permissions sends every setting you did not touch back exactly as it was. When the server refuses the save, the bar says Not saved and keeps your changes.

To hide one column from a role, set it to None. The section Attribute permissions below explains how.

CRUD permissions

At model and entity scope, five boxes control access, in the columns Create, Read, Update, Delete and Moderator. The tables below use the letters C, R, U and D.

Three rules apply automatically:

• Ticking Create, Update or Delete also ticks Read. You cannot write what you cannot see.
• Ticking Moderator includes all four boxes. Untick it before you save, and the row gets back the boxes it had before. After a save, unticking Moderator leaves Create, Read, Update and Delete on.
• Unticking Read unticks Create, Update and Delete.

Delete does not need Update, and Create does not need Update. The four operations are otherwise independent.

Effective combinations

Attribute permissions

Each column has a dropdown with four choices. Code, Name and the date columns that Primentra fills show a lock instead: they always follow the entity. Under an entity with no access, every column shows no access.

The entity permission decides which operations are available. The attribute permission decides what the user can do with one column during those operations. Both must allow it.

Examples:

• Entity CRU, attribute Salary = Read — the user edits rows, but the Salary field stays locked.
• Entity CRU, attribute Salary = None. The user edits rows and never sees Salary.
• Entity R, attribute Name = Write — view only. Write has no effect, because the entity grants no Update.

None is not the same as Follows entity

The two are different.

• Follows entity means "no opinion". The column takes whatever the entity level gives. If the entity has Read, the column is readable.
• None means "no access". The setting is stored, and it wins over the entity level. The entity can have full CRUD and the column is still hidden.

Code and Name cannot be set to None. Every row needs both to be recognized, so the dropdown does not offer it, and the server refuses it.

Where a hidden column is hidden

A column set to None is left out everywhere the user reads data. It is not grayed out. It is not there.

Writing to a hidden column

A write that touches a hidden column is refused. This covers a grid save, bulk edit, row edit, file import, REST API create and update, and submitting a change for approval. The refusal is the same one an unknown column gets, Unknown or hidden column., so it does not reveal that the column exists. A changed value for a read-only column is refused too, and that message does name the column. Nothing is written.

A required column blocks creating a row when the user cannot write to it. This holds when the column is hidden (None) and when it is read-only for the user. The save is refused with this message:

Existing rows are not affected. Only new rows need the required value.

Several roles: the highest level wins

Each role gives its own level for a column. That is the column setting of the role if it has one, and the entity level of the role if it does not. The user gets the highest of these levels.

Example. Anna is in two roles.

The highest is Read. Anna sees Salary.

To really hide a column, no role of the user may give access to it. Check every role the user has. The Permissions Report and Preview As show the result.

Administrators

Administrators always see and write every column. A None setting does not apply to them.

Limits

Column None is enforced by the Primentra application. It does not reach the places that work without a Primentra user:

• Staging tables: a system that loads data through the stg schema writes to every column.
• Integration views: a view returns the columns it was built with, whoever reads it.
• Direct SQL access: anyone with a SQL login to the database can read the values.

If a column must stay secret from these routes, keep it out of the view, and control who gets a SQL login. See Integration Views and Staging Overview.

Moderator and column settings

Moderator gives Write on every column that has no setting of its own: those columns show Follows entity: Write. A column setting still wins, also under Moderator. A column on Read (view only) stays read-only for a moderator of that entity, and a column on None (hidden) stays hidden. Set the column to Follows entity to give it the moderator's Write.

Domain fields

A domain attribute follows the same Read and Write rules. To fill a domain attribute, a user also needs Read on its domain source. Without it, the save is refused with You may not read Countries, so Country cannot be filled. A value the row already holds stays as it is. Administrators are not affected. See Domain Sources & Links.

Multiple roles

When a user belongs to several roles, the most permissive combination wins. Read plus Create-Read-Update gives Create-Read-Update. Columns follow the same rule: None on a column only hides it when no other role of the user grants it. See Several roles: the highest level wins above.

One exception: an entity with its own setting. When any role of the user has its own setting on an entity, Primentra uses only the entity settings of the user's roles for that entity. The model settings of all the user's roles do not count there.

Example. Erik is in two roles.

Erik cannot see Cost price: the own setting in Viewers replaces the model rights of both roles for that entity. To give Erik access, give Cost price its own setting in Editors too, or clear it in Viewers. The Permissions Report shows what each user gets.

Server-side enforcement

Every permission is checked on the server. A request that bypasses the interface is rejected with HTTP 403.

The same holds for columns set to None. The server leaves them out of every read and refuses every write to them.

Audit trail

Each changed permission is written to the audit log as a separate entry with Action = permission_change. Saving a role can therefore produce many entries at once. The Details field records exactly what changed:

{
  "scope": "entity",
  "modelId": 3,
  "modelName": "Customer",
  "entityId": 12,
  "entityName": "Branch",
  "roleId": 2,
  "roleName": "DataSteward",
  "changes": {
    "canRead": { "from": false, "to": true },
    "canUpdate": { "from": true, "to": false }
  }
}

For attribute scope, changes holds level instead of the CRUD flags. The level reads "none" for a column you set to None, and "inherit" when you removed the override. The permission update and the audit entry succeed or fail together.

Questions

I set a column to None but the user still sees it

Two things cause this.

1. Another role grants the column. The user gets the highest level of all their roles. If one role says None and another gives Read, the user sees the column. Open the Permissions Report for the user, or use Preview As, to find the role. Set the column to None in that role too, or take the user out of it.
2. The user is an administrator. Administrators always see every column.

If neither applies, check that you chose None (hidden) and not Follows entity. Follows entity removes the setting, and the column follows the entity level again.

I cannot save a new row, it says a column is required

The message reads Column "X" is required, but you have no write access to it. The column is required, and your roles give you None or Read on it. A row cannot be saved without a value you are not allowed to enter. Ask someone with write access to the column to create the row, or ask an administrator to change your access. Existing rows are not affected.

Can I hide the Name or Code column?

No. Code and Name cannot be set to None. Every row needs both.

Does None also hide the column in integration views and staging?

No. Those run without a Primentra user, so column None does not reach them. See Limits above.

Related

• User Management: create the accounts that join these roles
• Administrator & Moderator: the two elevated levels
• Preview As: check a role before handing it out
• Permissions Report: see the result across users and entities
• Configuring Approvers: what the Approver flag unlocks