ANW-2101: I was able to replicate the issue. At first I thought it may have something to do with her capitalization of the event type, but that had no bearing on the “translation missing” message.
ANW-2112: I was able to replicate this issue and confirmed that when a Name is associated with a subject that only an agent is created and not the subject.
I imagine this would be repeating the same work done for Conditions Governing Access, but for Conditions Governing Use. Recommend passing.
There are currently a lot of tickets requesting additional fields for the bulk accession importer. ANW-410, ANW-1861, ANW-1868 to name a few. Each request sounds as good as the others to me, but we may need to prioritize considering the bulk accession import spreadsheet is already 115+ columns wide. I think we should consider scope before making any recommendation for this one.
While keeping in mind notes from my second ticket, community feedback for ANW-1861 was overwhelmingly supportive. Recommend passing.
I may be misunderstanding the ticket, but I believe after v3.4 this does exist? You don’t need to be logged in to see the “Restriction” label on the top container view.
Use-case here makes sense and it’s well written. I think you can accomplish this with current functionality by checking a top container record associated with an AO that has a parent restriction. It’ll link out to the parent record that the restriction originates from. This functionality could be applied to the AO records themselves. Recommend passing.
Revisiting this. Want to check if we still believe using open-ended dates is valid behavior. It maybe for agents, but it seems to be in conflict with DACS 2.4. Is there a valid use-case? As one commenter described, a (better?) approach is to use a begin date with an empty end date for these types of dates.
Essentially asking for events to function more similarly to agents and linked resources/accessions. I can see how this could be useful, but the current workflow doesn’t appear to be significantly more arduous than an adjusted one. If passed, low priority. If not passed, I would recommend changing the label “Add event” to “Create event” to better indicate the intended function.
Since this is causing validation issues, it seems good to pass. The order is well-defined, so shouldn’t be overly difficult to add to the transformation. It sounds like forcing the order in ASpace instead (i.e. not allowing a form subdivision to be added after a chrono one) would cause issues with legacy data.