2019-8-8 Resource Access Meeting Notes

Date

08 Aug 2019

Attendees

Discussion Items

Time	Item	Who	Description	Goals
5 min	Housekeeping	Andrea Loigman		Notetaker - Cheryl Malmborg
20min	Reporting	Cate Boerema (Deactivated)	Request in-app report	Decide on best thin thread implementation for Requests overdue/missing in transit list (UXPROD-928)
20min	Requests	Cate Boerema (Deactivated)	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.