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.
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)?
The ability to run reports across repositories would be very helpful, but I’ve seen versions of this ticket closed before. The reasoning I’ve seen is that it’s a big lift, would not be widely used, and that it’s possible to achieve the same report via the API. I’m curious if circumstances have changed re: how significant of a lift this would be and/or if it would be more broadly applicable than before.
I was able to reproduce this bug. Digital objects are duplicated upon import. Recommend passing.
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.
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-)
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.
I don’t have access to Outlook to test, but the issue description sounds plausible. Suggesting copy/paste if clicking a link doesn’t work is fairly standard, so as long as clicking the link first doesn’t invalidate it completely, this seems like just an annoyance.
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?
Confirmed bug in sandbox - previously thought that upgrading to most current version relieved this issue, but still is occurring.
Ticket ANW-1862 requests that the trailing hyphen be supplied IN THE PUBLIC INTERFACE if the date is a single date, and the type is specified as Beginning. Would the date appear in the agent list viewed in the staff interface the same way?
This does appear to be a reasonable request for public display, though I also agree that data should not be added to the back end if it is not specified. However - May be instances where this behavior is not desired, if you really need to use only a single date. Not enough significance to pass - recommend closing.
I think this request makes a lot of sense. Currently when you look at custom report templates, only the name and description are included in the list view. I checked to see if there was a way to customize the view in the controlled value lists to no avail. Additionally, even when you click into a report there is none of this information included in the details of the report. A temporary fix would be to rely on the “description” field when creating/updating jobs to include the information about who created it and when. Recommend passing if its an easy enough fix.
Confirmed that this is an issue. None is showing up as only 2 items, when in actuality it’s over 200, as the ticket states, it’s unclear what is included in the “None” designation. I was only able to test this on the official ArchivesSpace test instance, when I look at my institutional instance there is no “none” examples.
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.