2020-05-04 Resource Access Meeting Notes

Date

Attendees


Discussion Items

TimeItemWhoDescriptionGoals/Info
2minAdministrivia Andrea Loigman
15minMVPHolly MistlebauerDiscuss RA related MVP slippage

  PO MVP Feature Status

15minFines/feesHolly MistlebauerFormat of refunds to process manually .csv and UIThis is the extract from which refunds will be processed. Scheduled for Q3 2020, but can't do refunds without this extract. Draft is available.
10minPermissionsEmma BoettcherExport loans permissionsPrioritize permissions for exporting user's open or closed loans and exporting all overdue loans
15minCirculationEmma Boettcher and Cate Boerema (Deactivated)Order closed: circulation actionsAllow/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/finesNamee.g. Q4 2018, Q1 2019Clearly stated decision
  • Because...
  • Because...
e.g. mock-up, JIRA issue
LoansEmma Boettcher
Permissions needed for being able to manually anonymize loans and export all overdue loans; permissions for exporting a user's loans can waitAnonymizing loans changes data; exporting overdue loans puts a burden on the system

LoansEmma Boettcher
No requests allowed on order closed items, and allow check out/check in with warningSimilar 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.