Permissions
Permission model
This page describes who may see and change what.
The two axes
| Term | Belongs to | Levels |
|---|---|---|
| Status | the account | 3, 6, 9 |
| Access | a thing (project, layout, field, event type) | No access, Read only, Edit |
Projects also have the level Deleted. Only status 9 sees deleted projects.
Every change to permissions takes effect immediately, whether on a project, layout, field, group, group membership or status. If a permission is withdrawn from someone, the server already rejects their next request, and a newly granted permission likewise applies from the next request. A page that is already open shows the new state after reloading.
Status
| Status | Label | Projects, layouts, fields | Admin areas |
|---|---|---|---|
| 3 | Individual read and write permissions | Only what permissions grant | no |
| 6 | Unrestricted | Read and edit everything, every permission table bypassed | no |
| 9 | Administrator | like 6 | yes |
Project permission
A project is visible to status 3 if it is not deleted and at least one place grants a permission. The highest level applies:
| Place | Meaning |
|---|---|
| Everyone row on the project | Base permission for all accounts |
| User tab on the project | For this account |
| Groups tab on the project | For all members of the group |
| Everyone | Account | Group A | Group B | Result |
|---|---|---|---|---|
| No access | not visible | |||
| No access | Read only | read | ||
| No access | Read only | Edit | edit (the most generous wins) | |
| Read only | read (for everyone) | |||
| Read only | No access | read. No access lowers nothing | ||
| Edit | edit (for everyone) |
In each row the project details show what already applies through Everyone and through groups, and next to it the result.
No access takes no permission away; it simply grants none. If you want to withdraw a permission, you have to find the place that grants it.
Layout permission
A layout appears as a tab when two independent conditions are met:
| Condition | Check |
|---|---|
| Assignment | The layout is switched on in this project |
| Permission | Everyone row on the layout or a group permission (for status 3) |
The assignment is not a level but a switch. It also applies to status 6 and 9: a layout that is not switched on appears for nobody.
| Switched on | Layout Everyone | Group | Status | Result |
|---|---|---|---|---|
| no | Edit | Edit | 9 | no tab |
| yes | No access | 3 | no tab | |
| yes | No access | Read only | 3 | tab, read-only |
| yes | Read only | 3 | tab, read-only | |
| yes | No access | 6 | tab (the status bypasses the permission) |
The layout permission is capped by the project permission.
Default for new projects switches a layout on when new projects are created. Existing projects do not get it afterwards.
Field permission
Three steps, in this order:
- Combine. The highest level from the Everyone row on the field and all the account’s group permissions.
- Cap with the layout. Nothing beyond the layout permission.
- Cap with the project. Nothing beyond the project permission.
| Field Everyone | Group | Layout and project | Result |
|---|---|---|---|
| No access | Edit | invisible | |
| No access | Read only | Edit | read |
| No access | Edit | Edit | edit |
| Read only | Edit | read | |
| Read only | Edit | Edit | edit |
| Edit | Edit | edit | |
| Edit | Read only | read, capped | |
| Edit | Edit | Read only | read, capped |
A field can only be reached through a layout that is switched on and accessible, or through the dynamic layout.
Consequence for fields that only some people should see
If a field is set to Edit for Everyone, anyone who may edit the project and layout can edit it. If you want to differentiate, there is exactly one pattern:
| Place | Level |
|---|---|
| Field, Everyone row | No access |
| Group that should edit | Edit |
| Group that should read | Read only |
Everyone else does not see the field in layouts and field pickers, and the full-text search gives them no matches from it. For a file field they also lose the files in it, both in the object’s file area and when retrieving the file, its transcript and its recognised text. Test this with an account with status 3.
Files
| The file sits | Who sees it |
|---|---|
| only in the object’s file area | everyone with read permission on the project |
| only in a file field | whoever may read the field |
| in a file field and also in the file area | everyone with read permission on the project |
“Seeing” here means: in the file area, in the full-text search across transcript and recognised text, and when retrieving the file itself. Status 6 and 9 see all files.
Edge cases
| Wish | Situation |
|---|---|
| Hide individual objects from certain accounts | Not possible. Whoever sees the project sees all objects in it. Separate them by project |
| A field editable in one project, read-only in another | Through capping: project A on Edit, project B on Read only |
| Explicitly withdraw a permission | Not possible. Only change the place that grants it |
| Allow reading, forbid export | Not possible. Whoever may read can export |
| Hide a file from individual accounts | Only in a file field with field permissions, and only there. If the same file is also linked in the object’s file area, everyone with read permission on the project sees it |
| A field editable on only one layout | Through capping: the other layout on Read only |
Libraries and special cases
| Area | Permission |
|---|---|
| Managing libraries (addresses, files, events, authority data, locations, plans) | Status 9 |
| Event types | Their own permissions, for everyone and per group, in Libraries › Events |
| Changing object links | Edit in the project in which the link is made |
| Link types | Their own permissions per type, for everyone and per group, plus restrictions per project, in Data model › Link types. See Link types |
| Linking to an object or a file | In addition, read permission on the target, that is, a readable project it is in. Without read permission the server answers as if the target were missing, so it does not reveal that the target exists. Authority data and addresses need no check of their own: authority data applies to the whole instance, and the address book is visible anyway to whoever may write in the project |
Further reading
- Roles and status : what each level opens
- Admin areas : which area needs which status
- Granting access : the procedure
- How permissions combine : why it is built this way