Skip to first unread message
Matthew Bruton
Jul 28, 2020, 1:42:04 PM7/28/20
to ica-ato...@googlegroups.com
Hi there,
Using Atom 2.5.
Have a quick question about controlling what users can view when they log in.
I have been able to control what they can edit, delete, update on certain collections and not on others.
However I would like to be able to control what they can view on other collections. Specifically, the problem is that I do not want them to be able to view items that are still in draft format on other collections. At the moment they can look around the other collections and view what other volunteers are doing on other collections, and I do not want that.
Can you help?
Matthew
Dan Gillean
Jul 28, 2020, 4:16:00 PM7/28/20
to ICA-AtoM Users
Hi Matthew,
First some relevant warnings and anecdotes - if you want to skip the TL;DR, I've bracketed it.
-----------------------------------------------------------------------------------------
I will start by saying that AtoM's permissions module is one of its oldest modules (built around the ICA-AtoM 1.2 release, with few modifications since), and is currently one of the modules most seriously in need of a complete overhaul to make AtoM more performant and scalable. The module works on a system of inheritance - from authenticated, to group, to custom group permissions, to user, to custom user permissions - and this is part of what makes it very slow at present. For each node on a page that can be controlled by the permissions module, AtoM must query all the way up the inheritance chain to check whether or not it can be displayed for the current user before loading it. When this is done dozens of times on a single page, the result can sometimes be that complex permissions will lead to timeouts before a page is even loaded.
One of the biggest areas where we've seen this is with "view draft" permissions - and this is usually the permission we suggest that organizations find a way to ease restrictions on when they are encountering timeout issues.
An example: I used to manage MemoryBC, the regional archival portal for the Canadian province of British Columbia. Like most provinces and territories using AtoM as their regional portal, at first the AABC (the association who maintains the portal) was very concerned about users potentially snooping on the draft records of others, and wanted to use the permissions module to restrict view draft permissions for all other institutions. A reasonable ambition, but the unexpected side effect that I discovered when I took over the position of managing the portal? Logged in users could not load authority record view pages - even though authority records actually have no draft status and are public by default. This meant that users would sometimes literally have to load AtoM as a public user in a separate browser just to view authority records! I believe this happens because of all the relations to descriptions listed on authority records - more nodes that AtoM had to check before loading. They also had a lot of custom group permission per-institution, making the inheritance very slow.
In the end, after consulting with their users, the AABC decided to ease this problematic permissions setting. Ultimately, everything in the portal was destined to be published when completed. Moreover, archivists are professionals, and it should be possible to trust other users not to snoop in your content unnecessarily - and realistically, most archivists don't have enough time to waste exploring other people's content anyway!
Once we removed this restriction, things went a lot more smoothly and logged in contributors were able to browse authority records again.
Now - there are a number of known bugs in the permissions module. They have not been resolved because at this point, fixing any one of them cascades into other issues that will require a complete re-implementation of AtoM's permissions. This is something we very much want to do, but it's a significant amount of work, and so far we have not found development sponsors. Having given this warning, I'll try to suggest how I'd approach restricting drafts, but I strongly suggest that you test everything thoroughly with a test user account AND an admin account, to check for unintended side effects!
-----------------------------------------------------------------------------------------
In general, with the inheritance model, it's best to try to put permissions restrictions as far up the chain as possible. The "authenticated" group supplies the base permissions for all other groups (except anonymous, which is your public users), and sets the base permissions inherited by all the other groups.
I would suggest going into this group, setting "View draft" permissions to DENY, and then going into the other groups where you want view draft permissions (e.g. Administrators, Editors, etc) and explicitly adding them back (i.e. setting to GRANT rather than Inherit) there.
If you need this group of users to be able to see some drafts, then I'd suggest doing the above, and then creating a custom group (e.g. Volunteers), and adding per-institution or per-description permissions there (i.e. allowing them to see all drafts associated with Repository A, or Description B, for example).
You could also try just leaving the authenticated permissions as-is, and setting "View draft" permissions to DENY in your custom group - try each out and see what works best.
A couple of gotchas as well:
When setting access control via the permissions module, note that the permissions will only restrict access to view and/or edit pages - it will NOT prevent authenticated user from potentially seeing draft results appearing in search and browse results.
Additionally, if you are trying to work with user groups who will be creating new descriptions, be aware that removing View Draft permissions may mean that as soon as they click Save on a new description, they are unable to see it! This is because the default publication status is typically Draft - you can change this default via the Admin settings, but then all your new records are immediately published (i.e. publicly visible).
Finally, regarding per-institution permissions, this is a place where you may encounter bugs, depending on what you're trying to do. See for example this recent issue ticket that I've filed:
This is likely more complex and less ideal than what you'd hoped for, but I hope it's at least helpful. Let us know how it goes.
Cheers,
he / him
On Tue, Jul 28, 2020 at 1:42 PM Matthew Bruton <matthewb...@gmail.com> wrote:
Hi there,Using Atom 2.5.Have a quick question about controlling what users can view when they log in.
I have been able to control what they can edit, delete, update and certain collections and not on others.
However I would like to be able to control what they can view on other collections. Specifically, the problem is that I do not want them to be able to view items that are still in draft format on other collections. At the moment they can look around the other collections and view what other volunteers are doing on other collections, and I do not want that.Can you help?Matthew
--
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/0979a2a8-cd6c-4e75-aca6-9c0f751453a3o%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages