Skip to first unread message
ism...@gmail.com
Jan 25, 2022, 4:48:34 AM1/25/22
to AtoM Users
Good morning, I am trying to create administrator users with certain permissions and I don't know if it is possible. At AtoM we have created multiple repositories with associated funds.
I would like an authenticated user to not be able to create or delete a repository, although they can update it and fully manage all funds related to it.
I have managed to give permissions to a user to see and update a repository without problems, but not so that he can manage the archive funds of said repository, is it necessary to give permission to each of the funds in addition? Greetings.
I would like an authenticated user to not be able to create or delete a repository, although they can update it and fully manage all funds related to it.
I have managed to give permissions to a user to see and update a repository without problems, but not so that he can manage the archive funds of said repository, is it necessary to give permission to each of the funds in addition? Greetings.
Dan Gillean
Jan 26, 2022, 10:02:07 AM1/26/22
to ICA-AtoM Users
Hi Isabel,
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 any question related to more complex permissions configurations in AtoM, I have to start by giving a standard warning. 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 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 some of the bug tickets that may be related to what you're trying to do, see for example:
So.... be aware that some aspects may not work, or that there might be unintended side effects.
Now, I did try to create the conditions you describe. What I found is that I could create a situation that seems to work as you wish, but only if I did NOT add the user account to any group - and definitely not to the Administrator group. I believe that administrator permissions may override some of the defaults, and fail to be overridden by custom per-user permissions, since this is a sort of super-group that access whole modules (like the Settings and Import tabs) that are unavailable to other groups.
Instead, what I did was:
- Create a new user. Do not add them to any group - they will automatically be part of the default "Authenticated" group by virtue of having an account. Save.
- In the Archival institution permissions tab, Set Read to Grant, and all other global permissions to Deny
- Add custom per-institution permissions for the user in the same page, and select the target institutions from the autocomplete
- Set all permissions for the target institution to Grant, and Save
- Flip to the Information object / Archival description permissions tab
- Repeat the process: set view/read permissions to Grant, and most other permissions (Create, Update, Delete, etc) to Deny. I set the digital object permissions to Grant to avoid any complications.
- Add per-institution description permission, and use the autocomplete to select your target institution
- Again, set all custom per-institution description permissions to Grant, and then save.
Here's what I ended up with:
A few basic tests seemed to work as expected. You could also try the same process with a custom Group, and then add multiple users to that group - I didn't test this myself, so it may run into some of the bugs linked above, but if you have multiple users per institution who need the same permissions, this is what I would suggest trying first.
Hope this helps - good luck!
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/d33e1f4e-2b35-4372-80f5-128418d14936n%40googlegroups.com.
ism...@gmail.com
Jan 27, 2022, 8:30:54 AM1/27/22
to AtoM Users
Hi Dan, thanks for the reply. Precisely the way you propose to create permissions is the one I was using, although I have already seen that the problem I have is registered in one of the pending bugs, we will have to wait.
In the end I have solved it by assigning specific permissions to each fund (informationObject) in addition to giving them to the repositories and it works for me. In this way, each user will only manage the repositories and funds that correspond to them.
I have another question, is it possible that an authenticated user can manage functions: create, edit at least?
Greetings.
In the end I have solved it by assigning specific permissions to each fund (informationObject) in addition to giving them to the repositories and it works for me. In this way, each user will only manage the repositories and funds that correspond to them.
I have another question, is it possible that an authenticated user can manage functions: create, edit at least?
Greetings.
Dan Gillean
Jan 27, 2022, 10:58:09 AM1/27/22
to ICA-AtoM Users
Hi Isabel,
Allowing other user groups to be able to add and edit functions has proven much more complex than I had hoped, unfortunately. So far nothing I've tried has worked, but I'll give you a summary in case you want to experiment yourself in a local test instance like the Vagrant box.
First, in the 2.7 documentation I've added a new section on a little known feature that can be used to extend permissions to groups in a few modules and places that don't have settings in the user interface's Permissions module. You can find this section in the Admin manual, here:
Essentially, several modules in Symfony have security configuration files in YAML, that a system administrator can edit to add or remove user groups, including custom groups. The documentation outlines a few examples, and some of the limitations of this approach.
There is a security config YAML file for the Functions module, but... I didn't include it in the new documentation, because it seems that it is being overridden by something else, and editing it to add other groups hasn't been working for me. However, you can find the file here:
Things I tried with this file:
- Removing all lines, and just adding is_secure: false
- Adding authenticated to the existing permission blocks
- Adding additional blocks for add, create, etc
- Combinations of the above
None of them worked, unfortunately. I'm not sure exactly why, but it seems to me like some other ACL check code is overriding this file.
Additionally, by default, an authenticated user does not have access to the Add menu. This I was able to solve by editing the following:
By adding in a new line for QubitAclGroup::AUTHENTICATED_ID, I was able to get the Add menu to show for my test authenticated user. However, clicking any of the Add menu's options generally still led to a Permission denied page - including Add > Functions, despite the YAML file changes made above.
Curiously, I then tried testing with the Contributor group. Even though the Functions security YAML file lists the contributor group in its existing permissions, my test Contributor could not add a new Function. It worked as expected for the Editor group, however.
I then started looking into other parts of the code to see if I could find where permissions were being checked. I found the following:
However, any attempts to comment out the permissions check here broke AtoM, so I don't recommend doing that :). I[m not well-versed enough in PHP to be able to suggest code edits that might work.
There are also further files in the ISDF plugin, but I'm not a developer and wasn't able to find anything that seemed obviously related to the permissions checks that are happening elsewhere.
I will see if any of our developers have some time to look into this a bit, but for now, I don't have a good solution for you. If your users need to be adding and editing functions, it's best to make them part of the Editor group for now.
Cheers,
he / him
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/d3547d31-6dbd-4c21-8a66-a077aebe979fn%40googlegroups.com.
Portales Municipales
Jan 28, 2022, 7:34:58 AM1/28/22
to AtoM Users
Hi Dan, thanks for the answer, for what you comment at the moment it is not possible to manage permissions for the functions. We will leave it in the hands of the administrator. Greetings.
Reply all
Reply to author
Forward
0 new messages