Insights needed about how AtoM handles the <audience> attribute.
53 views
Skip to first unread message
quenti...@gmail.com
Nov 22, 2018, 8:21:17 AM11/22/18
to AtoM Users
Hello !
We continue our extensive trial of AtoM (so far, we're more than satisfied), and I have some questions about rights management, groups, PREMIS, and the <audience> attribute.
It seems that AtoM allows administrators to create different user groups, each one with its own global rights (Read, create, update, publish, etc...).
We continue our extensive trial of AtoM (so far, we're more than satisfied), and I have some questions about rights management, groups, PREMIS, and the <audience> attribute.
It seems that AtoM allows administrators to create different user groups, each one with its own global rights (Read, create, update, publish, etc...).
I would like to know how AtoM handles the attribute <audience> relating to this right management system.
As an example, for non-logged users, given the fact that the 'Anonymous' group had the right to read,
I tried to publish some entities with audience=internal , but I couldn't see any effect.
As an example, for non-logged users, given the fact that the 'Anonymous' group had the right to read,
I tried to publish some entities with audience=internal , but I couldn't see any effect.
So, my first question : is the AtoM right management system taking full precedance over the 'audience' attribute ?
Second question : Let's say that I want non-logged users to be able to view only some archival descriptions, but not everything, only the ones I allowed.
What is the best way to achieve that ?
Thanks a lot for your time.
Best Regards,
Quentin
Thanks a lot for your time.
Best Regards,
Quentin
Dan Gillean
Nov 22, 2018, 6:11:43 PM11/22/18
to ica-ato...@googlegroups.com
Hi Quentin,
When you mention the <audience> attribute, are you talking about an EAD 2002 XML import?
If so, then the short answer is: AtoM is not currently configured to do anything with these attributes; they are ignored on import.
The explanation, which might hopefully answer some of your other questions:
The basic ability to hide an archival description from public view is handled by the publication status module. You'll find instructions on changing it on a per-descriptive hierarchy basis here:
This is in fact the answer to your second question - to be able to hide some but not all descriptions from public users, I would recommend using the publication status setting.
There's also a global publication status setting, that determines if new records are by default set to Draft (i.e. hidden from non-logged in users) or Published (i.e. visible to public users). See:
If you need to update the publication status for a bunch of records at once, you can't currently do this via the user interface, but there is a command-line task that might help:
AtoM also does have various other ways of controlling the visibility of elements, including:
- the Visible elements module: used to control the global visibility of certain specific fields in the archival description templates
- the Rights module: can be used to control access to and visibility of digital objects
- the Permissions module: used to set access permissions for users and groups, including the anonymous group (AKA public users)
Some notes on these modules and their limitations:
The Visible elements are a global setting - they can't currently be configured to control the display of individual fields in each description or descriptive hierarchy. This is one of the main reasons that @audience is ignored on EAD imports - it can be set differently on different fields in the same XML file, and even differently on the same field at different levels in a hierarchical description. AtoM currently has no way of implementing restrictions with this level of granularity. This would require significant development for us to implement, including an overhaul of the existing Permissions module to make it more scalable and performant.
Additionally, when fields are hidden in Visible elements, they are hidden from public users only - it cannot currently be configured on a per-user or per-group basis. Meaning: anyone who has the ability to log in can see them.
Finally, when fields are hidden, they are hidden in the public user interface - but currently they are NOT removed from the EAD / DC / MODS / CSV exports, or the finding aids if you've generated one (since it is generated from the EAD XML). The one exception to this is Physical storage information: if you've hidden this via Visible elements, and you've set your Finding aid generation settings to "Generate as public user," then the storage information is excluded from exports and finding aids. We'd love to add similar support for all fields in the Visible elements module, but it will require development - meaning we need community support to be able to implement it.
The Rights module's ability to restrict access to master digital objects and/or their derivatives operates somewhat similarly: the restriction is only enforced for public / unauthenticated users. Meaning you cannot restrict them on a per user/group basis, and anyone who can log in can see your restricted images.
Finally, we come to the permissions module. The first gotcha is that using this module to restrict view access to certain record types for public users (for example, changing the View permissions for authority records in the anonymous group settings to Deny in an attempt to restrict access to authority records) will prevent public users from accessing view pages (i.e. the full authority record), but it will NOT restrict them from searching and browsing authorities, seeing creator names linked to descriptions as creators or name access points, etc.
In contrast, the publication status module on archival descriptions is more comprehensive: if you set a record to Draft, it is also excluded from search and browse results. We would LOVE to add a publication status setting to more entities such as authority records, but again - this will require community support for us to be able to develop and add it to a future public release.
The permissions module also has a number of known performance/scalability issues, so I don't really recommend adding a ton of very granular permissions. I've discussed this in greater depth in the forum previously:
Cheers,
--
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 post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/45b94891-f17b-4ed1-9fda-5d9c8e659434%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
quenti...@gmail.com
Nov 26, 2018, 3:51:54 AM11/26/18
to AtoM Users
Hello Dan,
I have sent your explanation to our archivists, as it is very clear and complete for an end-user.
Seems that the way AtoM handles rights fits to them far better, as we will be able to have more granular control than a simple internal / external.
sorry for the late answer.
Yes, I was unclear, but talking about the EAD 2002 XML Import.
I have sent your explanation to our archivists, as it is very clear and complete for an end-user.
Seems that the way AtoM handles rights fits to them far better, as we will be able to have more granular control than a simple internal / external.
And in the case something is missing, we'll try to bring it to AtoM.
Thanks a lot for your time and explanations !
Quentin
Quentin
Reply all
Reply to author
Forward
0 new messages