Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
Do we want to do something? What kind of outreach do we want to try? Maybe an “Ask Us Anything” type of session. Please reach out to Matt and/or Bri in the next couple weeks if you have ideas. Deadline to submit is March 3.
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. Confirmed that it is still an issue in 3.4.
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.
This is a straight forward bug where a valid workflow validation error is happening and ArchivesSpace is erroring when it attempts to show the validation information to the user. It should be passed through to dev.
This is a valid concern and merits more research by developers into methods of secret value storage in Linux but that research may just result in publishing better guidance on appropriate system configurations for protecting this information.
The behavior is confirmed; however, I believe this is coming from a configuration they may not have set, see here.
While I cannot personally reproduce this, it seems that the issue of having to manually clear out this table has come up time and again. I would suggest setting the behavior Valery proposes as an optional configuration.
Regine will comment the fix she describes in the notes for the reporter in the ticket
I agree that retrieving a PUI PDF shouldn’t time out, but I wonder if a background job is the best way to do this.
Agree, and would suggest including the Relator if possible.
Pass, and rewrite ticket description to incorporate that this is a problem but a background job probably isn’t the right solution so some research is needed.
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.
Pass
Pass
Pass with recommendation that there needs to be better error reporting for date calculator
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.
Requested clarification and a use case. No response yet.
Documentation seems pretty intentional that Coll. Management records should only be at the collection level. Management information for specific objects can be recorded in the collection level note - a processing plan can be entered in text or a link to local document. One an also make use of the “Repository Processing Note” in each object. The assessments module could also be used at the object level to track specific processing needs and priorities. Recommend not passing.