Multiples Archival Institution to one instalation with user restrictions

[afto...@gmail.com]

Esteemed,

We are working on centralizing several archival institutions for a single installation of Atom. We would like to prevent a user from one archival institution from making changes to another that does not belong to their unit.

Has anyone managed to configure this Atom to work this way?

Thank you

Augusto

Examples:

User1, User2 write to "Archival Institution 1"

User3, Use4 write to "Archival Institution 2"

(...)

[Kody Whitt]

Hi, This is how we have our AToM set up. We have 3 archives that we ID with the identifier INT-#. You can add a user group from the manage tab in your Admin account. There you can set permissions based on Archival institutions for that user group. IE group one can only read INT-2 records but has full edit privileges for INT-1 records and group two can only read INT-1 records and can edit INT-2 records. Then you just assign your users to their relevant groups. The only issue that I have with this set up is I haven't found a good way to default the search on the patron end to default one archive over the other. I want to set it up so each institutions  landing page defaults to search only its own records unless a patron selects global 

[afto...@gmail.com]

Dear, I believe that the way you did in your system, we will be able to solve a part of our customizations. We will do the tests for implementation by groups and then return with the results. Thank you Augusto

[afto...@gmail.com]

Dear All,

During the implementation for rules, separating archival institutions by groups, I came across two intriguing situations.

- Revoking the user's "administrator" permission, the import button (csv, xlm, ...) disappears for the authenticated user.

Would it be possible to enable this function for authenticated "non-administrator" users?

- Also when I make the rule that a group only accesses its Archival Institution, privileges still persist in archival descriptions that are not in without a group.

Grateful for the attention

Augusto Torres

[Dan Gillean]

Hi Augusto, 

First, on the Import menu: 

I haven't tested this, but I think this is something you could change by adding additional groups to the following file: 

• https://github.com/artefactual/atom/blob/qa/2.x/apps/qubit/modules/object/config/security.yml
  

As you can see, currently both the import functionality, and the import menu in the AtoM header, are restricted to the administrator group. Here is an example of a file (for the Accessions module) that shows you what this should look like when multiple user groups are added: 

• https://github.com/artefactual/atom/blob/qa/2.x/plugins/qtAccessionPlugin/modules/accession/config/security.yml
  

So, for example, if you wanted Administrators and Editors to be able to perform imports, try changing the file above to look like this: 

  

import:
  credentials: [[ editor, administrator ]]

importSelect:
  credentials: [[ editor, administrator ]]  

all:
  is_secure: true

I strongly recommend that you test this on a development instance before trying it on your public-facing production site! 

You'll also want to restart PHP-FPM and clear the application cache after making changes. See: 

• https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/troubleshooting/#restarting-php-fpm
  
• https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/clear-cache/
  

Remember as well that your web browser has its own cache - so if you are not seeing changes, try clearing that and/or test in an incognito browser window. 

Your second question is more difficult to answer: 

- Also when I make the rule that a group only accesses its Archival Institution, privileges still persist in archival descriptions that are not in without a group.

As you may know, AtoM's permissions module is one of the oldest modules in AtoM, first introduced in either ICA-AtoM 1.1 or 1.2. There has not been major development of this module since this time - depsite the fact that AtoM has grown significantly, and people are using it for increasingly complex use cases with an increasing amount of records! Part of the challenge here is Artefactual's business model and the way we maintain AtoM - we rely on community support for major development, but while institutions are willing to pay for new features, it's very difficult for us to find sponsorship for refactoring existing modules, even when they need it. You can learn more about how we maintain and develop AtoM here: 

• https://wiki.accesstomemory.org/Development/Philosophy
  

 At this point, there are a number of known issues and bugs with the Permissions module that make fixing individual problems very difficult - we need to do a complete overhaul of the permissions to make them more performant and scalable, as well as clearer to end users. Artefactual does not have the resources to take on this scale of work without development sponsorship, but so far we have not found institutions interested in helping to fund this work. 

I have previously written about some of the known challenges with the Permissions module in the user forum, here: 

• https://groups.google.com/g/ica-atom-users/c/ot8ufFi-ZWY/m/0t2fPuBNAwAJ
  
• https://groups.google.com/g/ica-atom-users/c/Vq4fv8Vkr1M/m/i_e8ogk1AwAJ
  

Some of the known bugs that I suspect you may be encountering include: 

• https://projects.artefactual.com/issues/12118
  
• https://projects.artefactual.com/issues/13345
  
• https://projects.artefactual.com/issues/5420
  
• https://projects.artefactual.com/issues/5749
  
• etc...

In the long-term, Artefactual is currently investigating third-party open source libraries that deal with identity and access management (such as Gluu, Keycloak, the Open Identity Platform, etc). User management and granular permissions is a common problem that most enterprise-level software needs to address, and there is no reason for Artefactual or AtoM to build everything from scratch and reinvent the wheel if we can implement an open source library that is specifically focused on this area. 

Incorporating a new library for identity and access management (IAM) will likely be our strategy for any next-generation version of AtoM (aka AtoM3). However, it's also possible we could build a new component around one of these tools and integrate it with AtoM2 now, rather than trying to rebuild a new permissions module from scratch in AtoM2. Since we are committed to supporting AtoM, Artefactual will eventually find a way to get this work done - but with community sponsorship, this is something we could prioritize for an upcoming release, rather than target as a long-term goal. 

In the meantime, your best strategy is one of testing and compromise. In some cases, trusting your users to be respectful with each others' records and keeping the permissions minimal will be more successful than trying to implement complex and granular permissions in AtoM. One case we know can cause issues is trying to restrict View Draft permissions on a per-repository basis - this can cause timeouts for logged in users even when looking at other record types, such as authority records! See my second user forum post linked above for more on this specific topic. 

I know this is not ideal, but I hope that the information will help you find a compromise or workaround in your AtoM installation that will work for your needs. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

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/bfe495c8-1108-4566-a608-616c98a39dd6n%40googlegroups.com.