Anne Marie Lyons has commented that the user’s request can be accomplished through a custom report: “Search on recently created accessions that are Gifts and display the Content Description box. Also include and display linked Agents.”
The problem here seems to be an inconsistency in how bulk dates are labeled in the UI, in finding aids generated on the public side, and in finding aids generated on the admin side
This issue has been observed and reproduced by Anne Marie but does not happen every time and we’ve been unable to understand exactly what state causes it. I think it warrants investigated by developers, though so I’m suggesting it moves forward.
Doing more to help users understand that they are about to lose data makes sense to me and I think the effort of implementing these confirmation dialogs is worth the frustration it likely causes users so I’m suggesting that it moves forward as well. I’d defer to the developers to determine whether all of the suggested checks are possible, though.
This is being reported for the PUI in v3.4.1 and v3.5. I am unable to replicate the behavior that’s being reported either in the Sandbox or in Princeton’s testing environment. The example linked from the ticket returns 10 results [attempted 9/18/24], all of which have “1949” either in the date or in the title. None of them have “1949” in the uri.
The <unitid> tag is a red herring (it is part of the EAD serialization and holds the archival_object uri, not the resource uri).
The current accessions CSV creates agents and events on import. It is not very robust when it comes to knowing whether or not an entity already exists though (e.g. it works on the exact same string, but not on the exact same string in inverted order (direct/indirect), despite that property being set correctly. One question I have therefore is how to implement this robustly. Is this user envisioning entering a string value, just like with Agent links? I’m wary of adding more data entropy via CSV import. Would uri’s or id’s be acceptable instead?
Confirmed; also confirmed for character “$”. Recommend to pass.
I’m not fully understanding the request. Unless I’m missing something, it is not currently possible to associate Events with Top_Containers. This may be what they’re requesting; or it may be that they’re requesting that events associated with records are visible from the Top_Container record. Recommend to ask for clarification.
Close
Pass
Pass
Awaiting more information--ask user for clarification
It looks like the issue may be the lock wait time, which isn’t long enough to handle very large/long-running operations like moving many components. The issue doesn’t seem to prevent records from being moved, as they are in the correct place after the error. Suggested increasing the lock timeout locally.
This sounds like a great idea, although I would like to discuss potential ramifications before recommending passing.
Confirming that the era and calendar fields are not present in the bulk import template but would be good to have/add as the other ead required fields are already present. Recommend passing.
Confirmed that the action shown in video related to the reordering classification hierarchy is occurring and not preforming as expected (ie as reorder mode typically does as it relates to resources). Recommend passing.
Recommend passing - “authoritive is a misspelling - when reproducing this bug the hover-over tool tip contains the correct spelling of “authoritative”. Alternatively we can argue for the use of “Authorized”.
When creating an event the main identifier is the type of event + enumeration. Agents and linked records are visible in search results. Requestor would like to be able to assign a title in the Basic Information when creating events. This seems like a plenty useful feature and would help users search for specific events and disambiguate events of similar type more easily. Recommend passing, subject to discussion.
Possibly a terminology issue - “Add event” in this case really means “create event”. Allowing for events to be linked to resources from the resource page would make that process congruent to linking associated subjects, accessions, etc. Curious if there is a data model issue behind the difference.
Replicated error but in more specific circumstances: only when publishing via “Publish/unpublish all” button at AO level. Does not happen when using checkbox or publish/unpublish all at a level other than the affected AO. Error messages when there is no actual error are a problem, so this should be fixed.
Posted to user group email list for community feedback.
Confirmed in 3.5 sandbox. Recommend passing.
From our discussion last meeting: accepting “2010-” in the normalized date field is acceptable behavior. The issue is more so with the date calculator not handling these normalized dates correctly.
I definitely think this would be desirable. Recommend passing.
Type ahead will show all results including those with barcodes with dashes until you type a dash. At that point, no search results are returned. Recommend passing. It sounds like a similar issue was resolved in ANW-691 so hopefully no one would have to reinvent the wheel. Recommend passing.
1. There is a plug-in that should allow the user to hide these fields (https://github.com/hudmol/user_defined_in_basic ). This can be recommended as a potential fix. However, I also think automatically hiding unused user defined fields would be a worthwhile improvement.
ArchivesSpace documentation states that slugs cannot contain characters that are reserved or those that cannot be used in URLs, including non-alphanumeric characters such as colons, forward slashes, and others. This seems like a standard limitation on the formation of slugs/URLs, so I recommend closing.