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.” Recommend informing end user and closing ticket
I believe this user may be confusing the purpose of inclusive v. bulk dates: “Inclusive Dates” indicates the earliest and latest dates included in the collection. Sometimes, there will be a “Bulk Dates” listed as well, which means a large portion of the materials covers this more specific span of time. If present, this will be found under the inclusive dates. I do not see a bug or error here.
@Matt Strauss
I know earlier Dev Pri attempts to replicate this bug were not successful, but I’ve confirmed the described behavior in the ticket and attached videos in both the testing server and my organization’s installation. I think the bug could be more widespread than just this field - I’ve replicated the behavior with other controlled value defaults that aren’t required fields, such as Finding Aid Status and Description Rules. Recommend passing.
I agree that searching by a person’s actual name would be more a bit more straightforward than searching by username. However, I’m wondering about the development time required for a minor improvement. Also, would this even work as described (is the “created by” and “last modified” information even connected to staff agent records)?
@Brianna McLaughlin
1.
2.
@Dustin Stokes
1.
2.
@Dalton Alves
I was able to reproduce this and can confirm that it does break the date calculator. Normalized date fields accept dashes because they are used to form dates (ex. YYY-MM-DD, YYYY-MM). The normalized date fields should probably reject misplaced dashes at the end of an integer (ex. YYYY-, YYYY-MM-, YYYY-MM-DD-)
@Elizabeth Peters
1.
2.
Spreadsheets update with ASpace version, not continuously, so users should redownload a local copy each time their ASpace is updated. There may be a need for better local communication about updates.
@Regine Heberlein
1.
This is being reported for the PUI in v3.5.1. 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.
If this behavior was being observed in their local implementation in the past, I wonder whether they were indexing the resource/ref field of the archival_object record.
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?