Skip to first unread message
Omar Rivera
Apr 14, 2021, 4:21:07 PM4/14/21
to AtoM Users
Buenas tardes
Necesito saber como puedo restringir la edición de registros que otros usuarios crean.
Es decir darle acceso a un usuario editor a modificar sólo los registros que él mismo produce.
Cordialmente
Dan Gillean
Apr 15, 2021, 10:23:53 AM4/15/21
to ICA-AtoM Users
Hola Omar,
Unfortunately, this is not currently something that is easy to do in AtoM. This is for two main reasons: 1) the permissions are set up to work this way, and 2) there are some known issues with using very granular permissions in AtoM.
On 1:
In AtoM's permissions module, you can restrict permissions globally, by repository, or by description hierarchy. See:
There's not an explicit method for restricting permissions by user.
You might be able to find a workaround, though an administrator may need to make modifications throughout the process - I can't think of an easy way to just set this up and then have it continue to work for all future descriptions. However, an administrator could, for example:
- Create different temporary archival institutions, associate each user with an institution, and then restrict user permissions by institution. Later, the administrator could change the archival institution associated with the records to the main institution
- Restrict permissions to a particular description hierarchy once the top-level description is created. In this case, the administrator needs to intervene after the fonds/collection/etc is created, and then restrict permissions to that description. The user should be able to create new descendant records, but not add other new records. To do this you would essentially set the global permissions for all users to Deny for create, and then add permissions back in per user for the target hierarchy.
There may be other similar workarounds, but they will all involve some sort of monitoring by the administrator, with changes at various points, as far as I can think of right now.
However you may still run into problems because of issue 2!
On 2:
There's a lot that could be said here, but much of it has been said before. The short version is: 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 more information about how we develop and maintain AtoM, please see:
For a longer response on some of the known issues with the permissions module, see some of our previous responses on this topic in the forum, such as:
For more information about how we develop and maintain AtoM, please see:
For a longer response on some of the known issues with the permissions module, see some of our previous responses on this topic in the forum, such as:
Regards,
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 ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/bd2b20da-f306-4bed-b2a4-3c06ebd697adn%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages