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)
Confirmed Issue as it relates to sorting agents and subjects with resources, accessions, archival objects, and digital objects. The options to sort these agents and subjects appears, but after clicking the various options it continues to be sorted by relevance. Recommend passing.
Confirmed issue as it relates to Digital Object component labeling. The label appears in the backend as well as in the side bar navigation on the public facing side but doesn’t appear in the title after a given item has been selected. Recommend passing.
It doesn’t seem like reports support “include suppressed”. Do we want this to be narrowly scoped (e.g. include a “suppressed?” field in the report) or broadly (add “include suppressed” to all reports)?
This seems like a great idea - recommend passing.
Pass. Alexander will edit text of ticket to incorporate a wider toggle function to include/exclude suppressed records for all report types.
This has of course been the case for a long time but I have to agree from a logical standpoint that controls that “change the record” should maybe only be visible after entering Edit mode. Some other functions are in this same category such as adding events, and !merging records. Pending discussion - will recommend passing.
Based on email thread ("Adding more file versions to DO import templates?" May 28, 2024) sounds like the user would like the AO linking functionality of the Bulk Import spreadsheet with the full-field functionality of the DO Import CSV. Seems like a case of convergent evolution. We've had discussions before about why the spreadsheets shouldn't have a truncated number of fields compared to the manual entry. Would it make sense to pick which spreadsheet pathway we like better and deprecate the other?
Related to ANW-1837 which we discussed (and closed) in October. This is a different framing of the same issue, but I think presents a less duplicative and more easily actionable solution. Other solutions are possible, though – If it is more likely that a staff user would remember the date of the last upgrade than what version of ASpace they’re on, the file date of the downloaded spreadsheet would be sufficient. If this is easy enough to implement, could be worth covering all bases in order to close the gap between best practice and actual practice.
This ticket adds to ANW-1837 discussion of exported spreadsheets (Container labels, Container template, Digital object template). Since these include data from a specific resource, better to rely on the file date. Not sure why these would be saved and reused rather than redownloaded, though.
Pass. Keep bulk DO import spreadsheet and make sure it has all of the possible fields from the other digital object import spreadsheet. Elizabeth will edit ticket to identify which spreadsheet should be deprecated.
1.The reporter clarified that this request came from a prospective Lyrasis hosting client seeking a way to group politically sensitive collections for internal reference. I don’t think this would be a common use case, and similar functionality could be provided through the use of user-defined controlled values. I recommend closing the ticket.
2.This would increase the accessibility of digital objects on the PUI. I would suggest more descriptive text (i.e. “View Full Item”). Suggest passing.
Close
Pass, but need more discussion about language of link
I was able to reproduce the issue on the reporter’s instance, but could not reproduce the issue on the test server. Need more information.
This would definitely be a time saver. It’s possible to generate a report of all users and permissions, but you wouldn’t be able to deactivate at the same time like the reporter is requesting. Recommend passing.
Use case makes sense to me. Users may want to configure default values in a repository, but must rely on repository manager or admin level user to make changes. This reminds me of some of the configurability of permissions for Rapid Data Entry templates, controlled value lists, ect.
The location profile is part of the location record (which is linked to the top container). Some fields from the location record get concatenated (building, floor, room, coordinate, ect) and displayed within the top container module. I wonder if there’s some practical reason for not pulling in more data from the linked location record. This seems like a narrow use-case, could this be satisfied locally some other way?
This is a request to see Events associated with Top Containers from the top_container record. The reverse is already possible, i.e. one can see Top Containers associated with an Event from the event record. We had requested a use case, which they now provide (conservation). Another community member has chimed in to support the request. Recommend passing.
This ticket has also been discussed at the Usability meeting (comment by Brian) as a candidate for adding a configuration option. Personally, it makes more sense to me to see names with added qualifiers as the sort name, so I would recommend getting input from more stakeholders on this one.
Pass
Ask for more information about which name type the reporter is referring to