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 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)
Reminder that we have a tight turnaround for our June meeting. In the event that there are fewer new tickets, I’ll assign Awaiting More Information tickets. We will also be working on our Retrospective in June, so we may not need to fill as much time with tickets.
Pass: This would standardize combined labels so the CUI appears before the title, and appears it is already implemented in some places like the PUI Collection Organization tree.
I would like some input from the group. I am generally in favor of adding bulk actions, and ArchivesSpace already supports bulk delete in search/list views but not for archival objects in the resource tree. I can see how this could improve workflows around clean up.
Pass.
Re-write ticket w/ more info and pass. Different versions of this ticket/request have existed in the past. Have had difficulty figuring out how to implement. Reorder/tree mode is being actively worked on. Could leverage selection for re-order mode behavior in a similar way. Are their scenarios where trying to delete is not possible (what do we do when deleting hits an error/ect). Only reason for an error is probably if an AO is locked (opened by another user). Do we need to put this functionality behind a permission? Not a good idea to call it “bulk delete permission” because of semantics with existing delete permission. Maybe do config setting instead.
This is a follow up ticket based on community feedback for https://archivesspace.atlassian.net/browse/ANW-2271 . The was significant community feedback in support of making the order of sub-records configurable, so I recommend passing.
This one was a bit hard for me to understand, but I think it makes sense to pass.
This is something I have also wanted. Is there a search syntax strategy I’m missing?
This should be split into two tickets if we decide to pass either. Do we need to think more broadly about how subject subdivisions behave? Subjects and agents are already very different, so having agents as subjects creates issues. Having a different record for each set of subdivisions on a subject also creates issues.
Pass ticket as is. There is a work around for this. You can do a query like “resource:"{resource uri}.” Another work around is to do the search on the PUI and leverage the PUI → SUI “open record” feature (doesn’t work for unpublished records). Will share workaround in short term.
Awaiting more info. This could be revisited with a more comphrensive look at agent model in consultation with standards and metadata.
Going to go back to the requestor for more info. I don’t see the issue with the record that they linked unless they are talking about the facets. I believe the sort order has something to do with the intellectual arrangement (position of the AOs)? Are they asking that this view be sorted by physical arrangement (as indicated by child indicators)?
This request is technically feasible as the 'Current/Previous' can be surfaced in the SUI by modifying the Top Container results partial and Instance sub-record views. A somewhat narrow use case, but I imagine this would be useful to other institutions that leverage current/previous locations.
Recommend passing. The temporary status can usually be set, so it seems like a bug that it can’t be set via this particular process. There’s some extra logic around the temporary status, so it may need tweaking.
This is a request for a new feature in the PUI. This request seems more appropriate for another subteam, such as Usability.
Pass. Probably more of a bug than a feature request.
Very confusing ticket but I think I figured out what they are talking about and reproduced a failed merge in the Subject Source controlled value list (latest version sandbox). Agree better error messaging would be useful.
Tested, verified that I cannot get a <emph>tag to render properly when nested within a title tag. Nesting is possible using only the <emph> tags, but breaks when enclosing a title. Tested in 3.3.1 and newest version in sandbox