Any AtoM multi-department instances out there?
Kelli Babcock
I'm a Digital Initiatives Librarian (archivist at heart!) at the University of Toronto Libraries. We're currently scoping out the best archival description software to use at our institution.
We are conducting a pilot test with AtoM right now and have set up one AtoM instance to serve multiple departments across the UofT system. We're experiencing the following issues:
- The Accession Number field is too restrictive in a multi-departmental AtoM instance - multiple departments need to edit this field for their own legacy accession numbers. Can this field be free text?
- All users can access the same accession records/authority files/taxonomies. Can these be restricted to certain users, in the same way that the archival descriptions can be specified per user?
- Only admin users can import and export by csv - how can user permissions be editing at a more granular level?
Is anyone using AtoM as a multi-department instance? Have you come across these issues before? Any suggestions/resolutions? I've looked at Archeion but the use case does not match up - i.e. Archeion doesn't need to store accession records for institutions because it is geared towards discoverability.
Thanks so much,
Kelli Babcock | Digital Initiatives Librarian
University of Toronto Libraries | Information Technology Services
kelli....@utoronto.ca | http://its.library.utoronto.ca
Dan Gillean
- https://www.accesstomemory.org/docs/2.0/user-manual/add-edit-content/accessions/#add-a-legacy-accession-record
- https://www.accesstomemory.org/docs/2.0/user-manual/administer/settings/#accession-mask
Permissions
The authority record and taxonomies can be restricted by user or by group, but the accessions do not have a custom permissions module in the same way. Part of this is intentional - AtoM was designed as a multi-repository system for access, but was not intended to be a full descriptive solution for multiple repositories, with individual accessions modules for each repo. At artefactual we have looked into this, and feel that the complexity required of the code, combined with the challenges to performance and scalability that extremely granular permissions add, mean this is not currently a viable development option. We would rather see improvements so that multiple installations can share descriptive metadata for access (either via an API, or using OAI-PMH, for example), but where each institution wanting to use a full set of modules (such as accessions and physical storage) maintain their own local database.
We would really like to see the ability to associate authority records, and possibly taxonomies (or at least hierarchical term sets, such as subjects and places) with one or more repositories. This would require significant development, but we continue to hope that if this becomes a priority to the community, interested community members will either supply code, or perhaps work together to raise development funds.
As usual, if anyone is interested in having Artefactual prepare development estimates or quotes for particular enhancements, feel free to contact me off-list.
Documentation for existing permissions functionality:
Regarding CSV import and user permissions:
If you've seen our documentation for the CSV import (here) and looked through the user forum for some of the things that can go wrong, you will realize that CSV import is a complex functionality - and in general, it is best done via the command-line (only very small imports should be done via the GUI since this relies on the browser for parsing, which can easily time out, leaving half-formed corrupted rows in your database), and in all cases we encourage users to make database backups before importing this way.
This means that a high level of both knowledge and access should be expected of users performing bulk imports. In general, my feeling is that if you can't trust these people with Admin accounts, they probably shouldn't be doing CSV imports. I understand that you likely want to have students perform this work - but what I recommend instead is that students prepare the CSVs, and a trained archivist and a system administrator work together to perform bulk imports and reviews.
That said, we are working on introducing a job scheduler into AtoM (which will first appear in 2.2). This will allow tasks currently peformed via the browser to be completed by a "worker" asynchronously in the backgournd - so you can continue using the site without waiting in front of a blank screen for a task to finish, for example. In the future, this could allow for bulk import/export via the user interface, without being limited by the browser's timeouts. 2.2 will have the basic infrastructure in place, but we'll need further development to extend this to other core modules of atom, such as import. Once this is possible, it might make more sense to allow more user groups to perform uploads.
Note that in the interim, you could still assign Admin accounts, but use
the permissions module to limit the access of these users. However,
remember that the more granular permissions profiles you have in the
system, the more performance will be impacted. This is why we are also trying
to rewrite the permissions module for 2.2 - to address some of these
challenges.
If you have access to a developer, you could probably also alter the code to grant upload permission to other user groups by default.
I have heard of users editing the labels and menus, and using AtoM as a multi-departmental system (rather than multi-institutional), but I will let actual institutional users chime in with their responses.
On Arcan-L I noted that you asked about some of the other open-source systems - I will point out that nearly all of them have their own sandboxes/demo sites, where you can test out functionality yourself. I encourage you to explore your options, and let us know what you find! If you'd like to discuss the possibility of development to make the accession number field editable, or any other potential development work, please feel free to get in touch off-list.
--
You received this message because you are subscribed to the Google Groups "ICA-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 http://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/34be7b14-d895-47ae-a2a2-3c4e4fd0d9ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Grant McNulty (500 Year Archive)
Dan Gillean
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-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-atom-users@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/52eb22df-4b9d-4961-83b1-d4b5e66b4898%40googlegroups.com.