Skip to first unread message
Miquel Àngel Serra
Jan 24, 2024, 4:38:02 AMJan 24
to AtoM Users
Hello, I would like to know the minimum permissions that a user needs to view the contain of a physical storage unit.
I'll try to expose our case. We have a multi-repositorial installation (with AtoM 2.6.4) where every institution has their own user group that can manage the archival descriptions of their repository but have no permissions over the others. Now we would like to generate QR codes for every physical storage unit linked to an institution so the users of the institutiion could see the content of each box. The problem is that with the current permissions they don't have access to the storage unit module. Is there any way to grant this permission without giving access to the whole AtoM installation? (I could give them Editor permissions but then they would see the contents of every repository and we would like to avoid that).
Thanks in advance.
Dan Gillean
Jan 24, 2024, 1:02:37 PMJan 24
to ica-ato...@googlegroups.com
Hi Miquel,
First, I would like to offer a word of warning about how you are attempting to configure the permissions. 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. Additionally, AtoM was never designed to be a fully multi-tenanted system - the multi-repository functionality was added for ACCESS use cases, such as setting up a regional or national portal site; not having multiple different institutions edit and manage all their holdings in one application without being able to see the work of others.
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. This is particularly obvious when you start trying to add too many custom permissions. We'd like to do an overhaul, 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.
The main way that this manifests is that: when you try to add too many different custom permissions, you start encountering bugs and performance issues. 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:
Now, with that warning in place, I will try to answer your question.
Please keep in mind that the Physical storage module (like most of the internal entities, such as accessions, taxonomies, donors, rightsholders, etc) are NOT designed to be multi-tenanted. You will be trying to use the permissions in an unconventional way and may encounter performance issues, bugs, and more.
The permissions for physical storage in AtoM also do not have a user interface, like archival description permissions. Instead, they are controlled by a number of configuration files that set access policies for user GROUPS (you cannot currently set permissions for individual users for these modules). You can read about how these security configuration files are structured, and how to edit them to add or change group permissions, here:
A bit further down the page are specifics for the Physical storage configuration file:
You can create custom groups in AtoM and then add those group names to the security configuration files, and it should work. Remember to clear the application cache and restart PHP-FPM after editing any configuration files. It will be up to you to experiment and see how you can configure things for your needs, and what side effects that may have.
As a general piece of advice: a bit of trust in your archivists (who probably don't have time or inclination to go snooping in other people's data anyway) and some general agreed upon policies and procedures (around access, but also around naming conventions in shared modules like storage, accessions, etc), etc can go a long way - and that might allow you to relax how strictly you are trying to limit permissions, resulting in a better user experience for everyone.
If this really remains a problem, then honestly people should be using separate AtoM installations.
Cheers,
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/a3aabe11-9457-4bfc-85c7-83aca439c4d9n%40googlegroups.com.
Miquel Àngel Serra
Jan 25, 2024, 12:23:13 PMJan 25
to AtoM Users
Hello Dan, first of all, thanks for your answer. Very helpful as always.
Let me clarify a few things of the way we're managing permissions to see if it changes anything. We have an internal group of archivists (with Editor permissions over the whole installation) that when we start a collaboration with a new institution create their whole structure in AtoM and digitalize and upload the documents. Once we've finished we create a local user group with edition permissions over this archive where we add the institution's local archivists (they can see the whole installation but they only have edition permissions over their own archive). What I would like to do is to give permissions to these local user groups to see the content of each box when they scan the QR Code associated. So I would be giving them permissions as a user group, not as individual users. Does it change anything or the warning that you gave me about creating too many custom permissions prevail?
If I understood you correctly, we could add those local groups to the security configuration files to give them access to the storage module. As I only whant them to see the content of each box, I should add them under the Index key parameter, is that right? Is it safe to do that or it could potentially create bugs and performance issues as well?
Many thanks for your help and your advice.
El dia dimecres, 24 de gener del 2024 a les 19:02:37 UTC+1, Dan Gillean va escriure:
Dan Gillean
Jan 25, 2024, 2:22:33 PMJan 25
to ica-ato...@googlegroups.com
Hi again Miquel,
Does it change anything or the warning that you gave me about creating too many custom permissions prevail?
In the long run, there are a number of other factors that will affect this, so you will need to test and see. Without knowing your system resources, number of users, number of groups, how exactly you've configured the permissions for each, and the number of different records and types in your system, I cannot confidently give you an answer. However, in terms of optimization: if your custom groups can all have permissions to view Drafts, that will help a lot.
I spent some time working as the site administrator for MemoryBC (an AtoM provincial portal site in the Canadian province of British Columbia) where they initially attempted to restrict view permissions by institution as much as possible. The outcome of this was that whenever someone in one of these user groups attempted to edit an authority record - and in some cases, even to VIEW a specific authority record - the system would time out. This is especially bad since PUBLIC users with no authentication can see authority records! However, because the authorities were linked to institutions and descriptions, there were a number of layers of inherited permissions checks that the system was trying to perform for every node and link on the page, leading to a browser timeout before all checks could complete.
In the end, giving all user groups permissions to see all Drafts, and trusting that the archivists wouldn't go snooping in Draft records of other institutions (that would soon be published anyway, as it was a portal site and not a single institution's private archival system) was the one single change we could make that had the most impact on improving performance and allowing various groups to see and edit authorities again.
All this to say: keep things as general as you can. Only apply the restrictions where you feel they are really needed. Do some testing. If you encounter issues, you will have to consider what you might loosen to resolve the issue.
As I only want them to see the content of each box, I should add them under the Index key parameter, is that right? Is it safe to do that or it could potentially create bugs and performance issues as well?
Again, setting up some test groups and experimenting a bit will be your best bet. The index permissions should allow a user to see the physical storage information on the view page of an archival description, and click through to the full record in the physical storage module. However, without browse permissions, they can't go from there to generally browsing all storage containers, if I recall correctly.
Try it out and see, is my suggestion! Good luck!
he / him
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/b8b65fc8-b6f8-4e76-902b-1d3bdd5cd67cn%40googlegroups.com.
Miquel Àngel Serra
Jan 31, 2024, 8:42:36 AMJan 31
to AtoM Users
Hello again Dan. As you suggested I've been doing some tests trying to give permissions to our local groups but it hasn't worked so far.
I tried to add one of the groups under all the key parameters of the apps/qubit/modules/physicalobject/config/security.yml file but it hasn't changed anything. Could it be related with the fact that the culture of the group is not English and has no entry in English in the acl_group_i18n table? Or it has nothing to do with it?
Thanks!
El dia dijous, 25 de gener del 2024 a les 20:22:33 UTC+1, Dan Gillean va escriure:
Dan Gillean
Feb 1, 2024, 2:33:34 PMFeb 1
to ica-ato...@googlegroups.com
Hi Miquel,
That is a good theory, and it is definitely possible that your issue is related to i18n (internationalization) issues, which add a lot of complexity to the design and maintenance of features of AtoM.
I will ask our developers if they have any thoughts.
Cheers,
he / him
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/fe39ac9a-c803-43e7-86fd-ba0644cf3974n%40googlegroups.com.
Miquel Àngel Serra
Mar 21, 2024, 3:36:13 PMMar 21
to AtoM Users
Hello,
I've added an entry in the acl_group_i18n table with English culture of one of our local groups and that seemed to do de trick. Now this group can see the content of their boxes.
I just wanted to post it in case it can be useful for any other user.
Thanks a lot!
El dia dijous, 1 de febrer del 2024 a les 20:33:34 UTC+1, Dan Gillean va escriure:
Dan Gillean
Mar 21, 2024, 3:59:05 PMMar 21
to ica-ato...@googlegroups.com
Perfect, thanks so much for posting an update, Miquel! Glad you found a solution.
Cheers,
he / him
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/36791c49-e3ee-43cb-af85-c9cf4f4d0bb9n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages