Administration & permissions
- View
Administration in AtoM begins with the user, group and permission model that governs who can create, edit, publish or delete each type of description. Because AtoM is a multi-repository platform, access control is layered: authentication identifies the user, group membership assigns a role, and per-resource ACL rules refine what that role can touch. Getting this right is the difference between a safe production instance and one where a contributor can accidentally unpublish a whole fonds.
Sound administration also aligns with recognised information-security practice. If your institution follows ISO/IEC 27001 (built on the Annex SL high-level structure), the AtoM permission matrix is one of the technical controls you document as access management under Annex A.
Users, groups & the ACL
AtoM ships with default groups - administrator, editor, contributor and translator - each mapped to a set of actions. You extend this through Admin > Groups and Admin > Users.
- Assign users to groups rather than granting rights individually; groups keep the ACL auditable.
- Use per-repository and per-taxonomy permissions to scope an editor to a single archive or vocabulary.
- Set view, create, update, delete, publish and translate flags deliberately - deny by default, grant by exception.
Global settings & audit
Under Admin > Settings you control default publication status, description templates (ISAD(G), RAD, DACS, Dublin Core), inheritance of restrictions, and the visible elements. Pair this with a logging and periodic access review so entitlements do not drift over time.
Key takeaways
- Manage rights through groups, not individuals, and deny by default.
- Per-repository and per-taxonomy ACL rules scope editors precisely.
- Map AtoM's permission model to ISO/IEC 27001 access controls and review it regularly.