2020-05-04 Resource Access Meeting Notes
Date
May 4, 2020
Attendees
@Andrea Loigman
@Brooks Travis
@Elizabeth Chenette
@Jana Freytag
@Rameka Barnes
@Mark Canney
@Cheryl Malmborg
@Schwill, Carsten
@David Bottorff
@Joshua Lambert
@Cornelia Awenius
@Emma Boettcher
@Kimie Kester
@Cate Boerema (Deactivated)
@Holly Mistlebauer
@(OLD ACCOUNT) Erin Nettifee
@Laurence Mini
@Shirley Moentnish
@Donna Minor
@Andy Horbal
@mey
@Cornelia Davis
@HB Kouns
Discussion Items
Time | Item | Who | Description | Goals/Info |
|---|---|---|---|---|
2min | Administrivia | @Andrea Loigman |
|
|
15min | MVP | @Holly Mistlebauer | Discuss RA related MVP slippage | |
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 | Comments |
|---|---|---|---|---|---|---|
e.g. loans, fees/fines | Name | e.g. Q4 2018, Q1 2019 | Clearly stated decision |
| 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.