Follow up on Delivery fulfillment service points
The consensus was that Cate's hybrid model (see deck above) was the best way forward. A flag would be added to each Service Point to specify whether it could serve as a Delivery fulfillment service point (DFSP). A new field would be added to each Address in the Users app that would optionally allow for selection of a DFSP. It was decided to add this to the Address because some patron's might need to change DFSPs at various times of the year. Finally, when a Service Point is not a DFSP, an alternate DFSP must be chosen for that service point. This could either be done at the tenant or service point level. It was decided that the service point level was the better option. It was also decided that the DFSP should display in the request.
The question was asked if patron's could change their DFSP. This would depend on the configuration of the institution's discovery layer.
|15Min||Prohibiting "local" page requests: discuss design|
On 2020-07-30, Brooks raised the topic of a feature to prohibit "local" page requests. Many thought this was useful and/or necessary. Let's have a high-level discussion of what this might look like so we can make sure it is represented by a UXPROD feature.
Two ways were discussed to accomplish prohibiting local pages. The simplest option would be to add an 'Allow "local" page requests' button as part of the 'Page' request type. A more complicated but more flexible approach would allow the selection of which service points would be allowed as pickup locations. It was decided that more time was needed to ponder the matter. Cate asked that those interested in discussing the matter further contact her via Slack. Those already expressing interest in being part of the discussion were Cornelia, Erin, Andrea, Jana, Brooks, and Cheryl.
|10Min||Fast add records without barcodes|
I am writing a story that will automatically copy the barcode onto your clipboard/into check out app after the record is created. What should happen if there is no barcode specified? Should that be possible for fast adds?
There is (or will be in the future) a use case for Fast Add without barcodes (Electronic Reserves). It was discussed as to whether it would be possible to copy the barcode in checkout context, but not otherwise. The observation was made that the staff member probably has the barcode in hand if a barcode is needed. The general consensus was that barcode should be optional for Fast Add. If it is added and the staff member is in the checkout context, the barcode should populate the Scan items field in checkout. (Note takers note: For this to be useful, the patron info would need to have been scanned in before the user began Fast Add. Adding or changing a patron clears the item barcode input box.)
|5Min||Live Libraries Update||Nothing to report today|
Planned Release (if known)
Link to supporting materials
|e.g. loans, fees/fines||Name||e.g. Q4 2018, Q1 2019||Clearly stated decision||e.g. mock-up, JIRA issue|
|Fast add||Q3 2020|
Fast add records without barcodes:
|Requests: Follow up on Delivery fulfillment service points|
|Requests: Prohibiting "local" page requests: discuss design|