Permissions
Roles and status
Moliri has no named roles. It has three status levels and groups, and roles arise from the combination.
| Status | Label in Permissions › Users |
|---|---|
| 3 | Individual read and write permissions |
| 6 | Unrestricted |
| 9 | Administrator |
The levels in detail
| Can … | 3 | 6 | 9 |
|---|---|---|---|
| Log in, change own profile and password | ✓ | ✓ | ✓ |
| Open projects | by permission | all | all |
| Create and change objects, put them in the trash | by permission | ✓ | ✓ |
| See and edit all fields | ✓ | ✓ | |
| See all layouts | ✓ (if switched on) | ✓ (if switched on) | |
| Filter, sort, save views | ✓ | ✓ | ✓ |
| Bulk edit, export, import, upload files | by permission | ✓ | ✓ |
| Manage libraries, users, groups, data model, settings, history | ✓ | ||
| Create projects | ✓ | ||
| See deleted projects | ✓ |
What follows from this
Status 6 is not an administrative role. It opens all data, not the structure. The typical use is the registrar who may record and correct everything but should not change the data model.
You cannot test permissions with status 6. If you set up permissions, you need a second account with status 3 to check them.
Status 3 without permissions sees nothing. A new account sees an empty project overview as long as neither Everyone nor a group nor a direct assignment opens a project. This is not an error; it is the starting state.
Typical role setups
| Role | Status | Groups and permissions |
|---|---|---|
| Cataloguing | 3 | Edit in their own project, cataloguing layout, subject fields |
| Conservation | 3 | Edit in their own projects, conservation layout, condition fields |
| Education, research | 3 | Read in many projects, overview layout |
| External staff, interns | 3 | Edit in one project, a reduced layout, no sensitive fields |
| Registrar, head of collections | 6 | none needed |
| Database administration | 9 | none needed |
Groups
A group is a set of accounts through which permissions are granted. It has no status of its own. In Permissions › Groups it has the tabs Users, Projects, Layouts and Fields. Permissions on event types are granted on the type itself in Libraries › Events.
An account can be in any number of groups. The permissions combine, and the most generous level applies in each case.
Two patterns that work well
By activity (recommended): Cataloguing, Conservation, Loans, Education. A group bundles the layout and fields of one activity, and you grant project permissions on the account.
By project: Spring exhibition, Prints collection. A group bundles the project permissions, and layouts and fields are open to everyone.
Mixing the two works but quickly becomes hard to follow. The first choice is the split by activity, because activities last longer than projects.
Settings on the account
| Setting | Remark |
|---|---|
| Name, Loginname | Display and login |
| Status | 3, 6 or 9. You cannot change the level of your own account |
| Groups, Projects | Only visible as tabs for status 3 |
| Change password | Set by the administrator. Not applicable if the account logs in through single sign-on |
| Password reset on next login | The person sets their own password the next time they log in |
| 2-Factor authentication | One-time password for this account, see Login |
| Valid until | From this day on, logging in is no longer possible |
| Chat Support | Support chat for this account |
| Last login, Failed login attempts | For checking. The counter can be reset |
Further reading
- Permission model : the decision tables
- Admin areas : which area needs which status
- Creating a user and Creating a group : the procedures