Skip to first unread message

Apr 12, 2022, 11:54:48 AM4/12/22
to AtoM Users
I get confuse with the rights and the users. I mean I have to set the doc rights : RESTRICTED, OFFICIAL and PUBLIC.
I can avoid the doc displaying to a generic user by "the Act/Diplay disallow", but if the user is logged in, he can access to document. 

Now how can I associate the doc rights to the users? For example:
user1 can access to the docs RESTRICTED, OFFICIAL and PUBLIC
user2 can access to the docs OFFICIAL and PUBLIC

Thnaking in advance, regards

Dan Gillean

Apr 13, 2022, 1:15:36 PM4/13/22
to ICA-AtoM Users
Hi Sergio, 

Currently, there is no direct connection between user permissions and the actional PREMIS Rights module. 

The actionable PREMIS rights in AtoM can currently only be configured to control the public visibility of digital objects. Useful if you want your end users to know there is digital content available, but which you can't directly make available (due to agreements, copyright, policy, etc). However, as you've noted, anyone who can log in will be able to see the original digital objects. This is similar to the behavior used in the Visible Elements module, which can hide individual metadata fields in some templates, but only for public users. Note that for PREMIS Rights, only authenticated users can see the actual Rights statements added to records - public users will only see the access statements you configure to display in place of digital object derivatives. 

It is technically possible to further restrict access for authenticated users, by using the User and Group permissions:


However, there are some known issues that I want to mention. 

First, there are some known bugs and scalability issues with the permissions module in AtoM that may cause problems if you are applying a lot of custom permissions. AtoM's permissions module was first added over a decade ago (when the application's primary use case was small to medium archives, with simpler permissions needs), and unfortunately, while AtoM's user base has grown exponentially and the ways in which the community attempts to use it have multiplied, the permissions module has not received any significant overhaul. Consequently, there are many known performance and scalability issues, as well as a number of bugs that are difficult to change without performing a full rewrite. We'd like to do this, but it's a major piece of work - meaning that for Artefactual to take it on, we'd need community support, either in the form of community code contributions or development sponsorship. So far no one has been willing to fund the level of work necessary to truly address these issues.

For further details on some of the known issues with the permissions module, see some of our previous responses on this topic in the forum, such as:
Related to this: to make this work, you would need to apply the permission either per description or per-repository, so it may be a lot of work if you have many different descriptions with digital objects, all falling into these 3 different access categories. 

Without knowing more about your particular needs and installation, the best recommendation I can make is to do some experimentation, and see if you can make the existing options in AtoM's permissions module work for your needs. Try to make changes in groups rather than individual users, and make compromises where possible - the simpler you can keep your permissions, the more likely it will be to work. For general guidance, see:  

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
he / him

You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit
Reply all
Reply to author
0 new messages