2020-05-04 Resource Access Meeting Notes

Date

04 May 2020

Attendees

Discussion Items

Time	Item	Who	Description	Goals/Info
2min	Administrivia	Andrea Loigman		Notetaker - Joanne Leary
15min	MVP	Holly Mistlebauer	Discuss RA related MVP slippage	PO MVP Feature Status
15min	Fines/fees	Holly Mistlebauer	Format of refunds to process manually .csv and UI	This is the extract from which refunds will be processed. Scheduled for Q3 2020, but can't do refunds without this extract. Draft is available.
10min	Permissions	Emma Boettcher	Export loans permissions	Prioritize permissions for exporting user's open or closed loans and exporting all overdue loans
15min	Circulation	Emma Boettcher and Cate Boerema (Deactivated)	Order closed: circulation actions	Allow/disallow check out, check in, or requests for item with the item status Order closed

Meeting Outcomes

Functional Area	Product Owner	Planned Release (if known)	Decision Reached	Reasoning	Link to supporting materials
e.g. loans, fees/fines	Name	e.g. Q4 2018, Q1 2019	Clearly stated decision	Because... Because...	e.g. mock-up, JIRA issue
Loans	Emma Boettcher		Permissions needed for being able to manually anonymize loans and export all overdue loans; permissions for exporting a user's loans can wait	Anonymizing loans changes data; exporting overdue loans puts a burden on the system
Loans	Emma Boettcher		No requests allowed on order closed items, and allow check out/check in with warning	Similar to other statuses where item is not expected to be physically in the library

Notes

PO MVP Status Review

Holly discussed the PO MVP Status spreadsheet which shows current statuses of JIRA issues and the revised projected quarter in which the issues will be resolved. (See column F to filter on issues that have been delayed.) She noted that some issues have been split out to allow for more achievable implementation. Issues needed for 2020 implementation have been prioritized. Everyone should review the spreadsheet for concerns, and discuss on Monday. Erin and David noted that implementers will have to look at the projections for two quarters earlier than their planned implementation date, to allow for testing and preparation based on that quarter. Additionally, since these are projections, there is no guarantee the issues will be resolved in the designated quarter.
In terms of permissions, general agreement that patron block overrides are more important to have functional than item block overrides (though both are important)
Holly is looking for user stories to provide context for the importance of the issues; feel free to send her some story examples

Fines/Fees Refunds to be Processed Manually

We reviewed the prototype in-app report that shows fine/fee refunds to be processed manually – are there any elements that are still needed on the report? Suggestions:
- item barcode
- item title
- Fine ID (which is very lengthy) should be placed as the last column, and perhaps converted to a link to take the user to the actual fine record
Question: should there be a separate permission level to be able to export the results, or is it OK to have view/export the same permission level? Although there are some security concerns with being able to export confidential information outside of Folio, perhaps higher level of permission is not needed, since a person at a view-only level can circumvent any such restrictions by copying/pasting the viewed results into a document or spreadsheet.
Any other thoughts about other fields needed on the report, please message Holly on Slack

Permission issues – Emma

We are asked to prioritize the need for various export functions as “need to have” or “nice to have”

Export Loans to be anonymized – need to have, and as separate permission
Export list of all overdue items – nice to have (Q: what impact would this have on the production system?? – probably needs separate permission since user really needs to understand what they’re doing)
Export a user’s open loans – nice / need to have – can be bundled with closed loan export (?)
Export a user’s closed loans – nice to have – can be bundled with open loan export (?)

Order Closed item status – action behavior

For any item that was on order (and item record was created), but was never received (or never got processed as received by mistake), what to do if the item has a request on it? Item record cannot be deleted unless the request is removed. What should happens if:

Item is checked out – allow, but show a warning
Item is discharged – allow, but show a warning
Item is requested – don’t allow new requests. Some notification should happen when an item’s pre-existing request is deleted – either for processing staff, or for circulation staff, so the requestor can be notified. An “order closed” status should block a new request (could not verify). The notification step could ideally be part of the processing workflow, when that becomes a reality. Carsten noted that they would like to enable patrons to place new requests on items that have an “on order” status – seems like this should be standard behavior if the on-order item is visible in the discovery layer.
Item is “checked out” or “in transit” – cannot change an item’s status to “order closed.” Should have a pop-up alert.