2019-8-8 Resource Access Meeting Notes
Date
Attendees
- Andrea Loigman
- Anya
- Cheryl Malmborg
- Joanne Leary
- Cate Boerema (Deactivated)
- Darcy Branchini
- Catherine Smith
- Jana Freytag
- Donna Minor
- Elizabeth Chenette
- Kai Sprenger
- Kelly Drake
- Kim Ammons
- Magda Zacharska
- Mark Canney
- Sharon Wiles-Young
- Rameka Barnes
- William Weare
- Cornelia Davis
- Andy Horbal
Discussion Items
| Time | Item | Who | Description | Goals |
|---|---|---|---|---|
| 5 min | Housekeeping | Andrea Loigman | Notetaker - Cheryl Malmborg | |
| 20min | Reporting | Request in-app report | Decide on best thin thread implementation for Requests overdue/missing in transit list (UXPROD-928) | |
| 20min | Requests | Request expiration period | Default Setting for Request Expiration Period (UXPROD-1628) - Can we thin thread this by agreeing on a sensible default for this? Maybe 6 months out? |
Meeting Outcomes
Functional Area | Product Owner | Planned Release (if known) | Decision Reached | Comments |
|---|---|---|---|---|
Notes
Andrea reminds us to review inventory xprods as they pertain to RA
Cate-Discussion of request in-app report of requests overdue/missing intransit
Can this be thin-threaded for MVP using csv export of request with open-intransit status?
Would need to add columns for the date the item went intransit and the service point it went in transit from (checkin date/checkin service point)
Andrea- What is really wanted is a report of all items with the intransit status whether or not they were requested (for efficiency of searching)
General agreement on this.
This would be a report on item status from the inventory module with a join on the request table to distinguish requested items (requested items usually would be prioritized for searching)
Darcy-Instead of last checkin date/service point should use last scanned date/service point. Items may be mis-routed and scanned again. It would be good to know the last place an item was handled.
Cate will do a mock up of a items in transit report. Developers will need to analyze of feasibility of running in-app and joining with requests
Columns that could be cut from the request in-app report:
hold shelf expiration date, position in queue, request status, contributor?, current due date, requestor name, requestor barcode,request fulfillment point,delivery address, requestor proxy name and barcode
Columns to change or add:
change pickup service point to destination service point (pickup or home location)
add request creation date and probably keep request expiration date
add sortable call number including prefix, suffix and enumeration (sortable call number doesn't currently exist)
Request expiration date currently has no default. It must be entered with each request.
The thinnest thread to provide a default would be a hard-coded value for all institutions.
The group would prefer a tenant-level default for the MVP.
For future development setable defaults by library(service point?) and request type.