Confirmed typeahead does not accommodate hyphenated entries (v2.7.0) Recommend: pass (replace common typeahead scenario punctuation with spaces)
Confirmed controlaccess title tags are skipped during EAD import (v2.7.0) Confirmed controlaccess title is included as subject object during EAD export (v2.5.x) Recommend: pass (include uniform title tags as subject objects durning EAD import)
Confirmed EAD import adds non-standard values to enumeration field Date Type (v2.7.0) Christine reached out to Laney McGlohon for additional information (2017) Attempted to identify solution by examining sourcecode...data validation could be possible solution...inability to add/modify/delete new date types (enumerations) through AS interface can be problematic Recommend: more information needed to unveil depth of problem and solutions
Pass
Pass
Add a comment to the ticket that specifies passing this contingent on adding any enumeration fields that are uneditable through the interface or API should fail with an error message that is helpful and informational.
We’ve had this issue, our workaround is to manually edit the record and save it so it is reindexed into existence. Recommend: pass
I could not find documentation about endpoint permissions required to confirm if the search endpoind indeed only requires view_all_records but this should probably be looked at. Recommend: pass?
Is there enough information for the devs to take this ticket over? Recommend: pass contingent on Dev response.
Pass
Pass but also contact the tech docs and API task force to review API permissions and authentication per endpoint. @Edgar Garcia (Unlicensed) to add a comment.
[LT update: status changed, pending Edgar’s comment]
3. Move to Waiting for More Information and ask the community if there is interest.
Unanimously positive responses about this ticket after sharing it on the list. However, it would be a lot of work. Maybe put it on the community developer list?
4. This ticket is very thorough and Usability met with her to try to make mock ups. Unfortunately, none of us are that artistically talented. Is there enough info for developers to at least start making improvements on? We’d love for it to pass.
Move to Awaiting More Information and lower to Trivial. This requires a revisit to what should happen as a solution.
Reproduced on 2.7. RDE button should be removed. Recommend passing, but reducing priority to trivial, since it doesn’t cause any problems.
Main entry is only relevant for MARC XML export, as EAD does not make this distinction. Current mapping is that the first agent listed as creator is exported as the main entry (1xx field). In the absence of any explicit need for having the main entry status applied prior to export, I recommend passing as trivial or closing.
This seems to have been resolved, probably as part of Lora’s update. Recommend closing as done.
This ticket provides a very clear (and referenced!) explanation of the usability problem with the current display of the digital object button in the PUI and mocks up two options for addressing the issue. The cited sources provide greater support for the hyperlink option (no. 1) compared to the button option (no. 2). Unless there is a need to retain the button style for consistency with other site elements, I recommend choosing option 1 and passing.
Pass
Close. No change. @Daniel Michelson to comment why.
Close as complete. Not relevant.
Pass option 1. Restate as a comment the differences between options.
[LT update: status changed, pending comment from Daniel]
Unless there is a specific reason why Location Profiles and Event records are not directly editable from a list of results, I recommend implementing this request.
Agree that this issue should be addressed. All notes should obey user publication preferences by default. Beyond that, when tailoring at the archival object level in RDE, the decision to make is whether to have all fields obey publish/unpublish uniformly or to provide publish/unpublish option for every note field. I would support having an option for Note 1/2/3, if viable.
I haven’t been able to replicate this but agree that extent_number should export along with extent_type in CSV.