How permissions combine

Moliri has two notions of permission. Almost all confusion arises from taking them for one.

The status belongs to the account. It answers what this person is allowed to do at all. There are three levels: 3, 6 and 9.

Access belongs to a thing: a project, a layout, a field, an event type. It answers who may do what with this thing. It also has three levels (No access, Read only, Edit) and can be granted to everyone, to individual accounts or through groups.

The status levels

This leads to something that is easy to overlook during setup: access only makes a difference for status 3. Anyone with 6 or 9 sees everything, including the field that was just meant to be hidden from a group. That is why permissions can only be checked with an account that has status 3.

Combine first, then cap

Together, two rules explain every individual case.

Permissions combine, and the most generous level wins. A permission can come from several places: from the basic permission on the thing for everyone, from an assignment to the account, from any number of groups. Moliri takes the highest of them. A weaker level never lowers a stronger one. There is no way to forbid, only to not allow.

Project and layout are the upper limit. Once the field permission has been combined, it is capped by the layout permission and the project permission. Someone who may only read a project cannot edit any field in it, even if the field is set to Edit for them. Keep this rule in mind when a permission seems to have no effect.

Why there are three levels

They answer different questions.

The project permission decides which undertakings a person works on. This is the coarse control, and many museums manage almost entirely with it.

The layout permission decides which input forms they see, so that the conservation team does not have the loans form in its way. A layout needs two things: it must be switched on in the project, and the person needs a permission for it. If either is missing, the form is gone. This is the most common cause of “I can’t see the form”.

The field permission decides about individual pieces of information. It determines who gets to see which fields in layouts, field selections and the full-text search, and for a file field also the files in it. Purchase prices, insurance values and loan agreements can be hidden in this way from accounts that should not see them.

Making a field editable is a decision

The field permission acts as a limit in both directions. If a field is set to Read only for Everyone, nobody with status 3 can edit it unless a group grants Edit. If you want to distinguish, set the field to No access for Everyone and grant permissions selectively through groups. The tables for this are under Permission model .

Where the model ends

Individual objects cannot be hidden. An object in a project is visible to everyone who can see the project. If you need to keep objects apart, keep projects apart.

Managing the libraries requires status 9. The exception is event types, which have permissions of their own per group.

An object’s file area has no field permissions, because a file linked there is not attached to any field. Anyone who may read the project sees it and finds it through the full-text search, including via its transcript and recognised text. Files in a file field, on the other hand, follow the field’s permission. If the field is hidden from someone, the file is also missing from their file area, and neither the file nor its transcript or recognised text can be retrieved by them. A loan agreement that only some people should see therefore belongs only in a file field with suitable permissions. If you also link it in the file area, you release it to everyone with read access to the project.

Further reading

• Permission model : the decision tables
• Roles and status : what each level opens up
• Administration areas : which area needs which status
• Grant access : the procedure