Who | Topic | Notes | Decision | | | |
---|
Matt Strauss /all | Welcome | Virtual Member Forum presentation recap Presentation at UAC April meeting | Went well! Demystified process for viewers and answered a lot of good questions.
| | | |
Mattie Clear |
| Confirmed Issue as it relates to sorting agents and subjects with resources, accessions, archival objects, and digital objects. The options to sort these agents and subjects appears, but after clicking the various options it continues to be sorted by relevance. Recommend passing. Confirmed issue as it relates to Digital Object component labeling. The label appears in the backend as well as in the side bar navigation on the public facing side but doesn’t appear in the title after a given item has been selected. Recommend passing.
| | | | |
Regine Heberlein |
| The use case here is merging repositories or instances where the same (generic) label is used to designate different profiles. I’m not sure the reporters have a compelling case, but perhaps I’m missing something? Allowing the same name for different profiles seems counter-intuitive, and we would have to then solve the problem of how to select the correct one from a drop-down (e.g. with a qualifier). So my intuition is to not pass, but let’s discuss--maybe I’m not thinking about it right. I don’t have the ability to reproduce this in my setup, but they’ve obviously looked into it with their developers, who have a hypothesis. I think the ArchivesSpace developers need to weigh in on this.
| Close. Recommending to reporter that it might make more sense to switch the unique field to dimension instead of label. Awaiting more information--comment that ArchivesSpace developers are looking into it. Assign to Thimios
| | | |
Bonnie Gordon | 1. 2. | This is the referenced template. Use case seems applicable to other institutions, which is backed up by comments on the ticket. Pass. I agree that this is confusing, and the badge does not seem to be explained in the user docs. Is there more context for this term?
| Pass Rewrite ticket to recommend removing Authoritative label altogether.
| | | |
Dalton Alves | 1. 2. | Agreed that outline hierarchy and structure is very confusing. Also agree that moving items between levels would simplify creation of outlines. Not sure if this is a bug, but rather a feature request? Also, any enhancements to agent chronologies should probably also be applied to resource record chronologies. This could be broken into many different feature requests. Many of the notes on this ticket are related to search functionality of top containers – could start there.
| Pass and recommend in comment that it would be helpful to other fields using <list> including bibliography notes and index notes. Close and request user resubmit as multiple tickets
| | | |
Brianna McLaughlin | 1. 2. | Was able to reproduce bug. It is currently impossible to save a location as “previous” unless the location is marked as temporary. Since a non-temporary location can be a previous location for a container in various use cases, it does not make sense that a location must be “temporary” in order to be a previous location. Reporter suggests Remove the requirement that a linked location can only be set to status “previous” if the location itself is marked “temporary.” Recommend passing. User requests adding Resource URI to custom report template options. Their use case is achievable via exporting browsing results. Recommend closing unless adding Resource URI would be simple to add to a custom report template.
| Pass Pass
| | | |
Matt Strauss | 1. 2. | 1.I reproduced the error for <langmaterial> but not <dao> and <daogrp>. I’ll see if I can procure an example of problematic EAD from the requester and investigate further. Have confirmed the behaviour here and agree that it is not ideal. Importing related agents will also overwrite a corresponding existing agent
| Pass for <langmaterial> Pass
| | | |
Dustin Stokes | 1. 2. | | | | | |
David Krah | 1. 2. | | | | | |
Elizabeth Peters |
| As far as I can tell, linking to an existing resource or AO is required on the current bulk import DO spreadsheet Recommend passing, but may require more conversation about how to implement. Would need to address similar issues as Agent linking currently has in upload spreadsheets: link to existing DOs without changing them or creating new ones. Could use similar functionality to DO import and Top Container spreadsheets, using unique ids. Field would need to be repeatable, like top containers are.
| Hold for next meeting Pass and recommend functionality to link by DO identifier instead of name to avoid overwriting/duplication
| | | |