2020-08-24 Resource Access Meeting Notes

• A while back, we reviewed this deck describing the challenge and some potential solutions:

https://docs.google.com/presentation/d/1FIzV1P7va_3yX0oLE7XauGPLZHA05NTOFutto_QNybg/edit#slide=id.p.

• Many SMEs in that meeting (from Duke, Cornell, Chicago, MSU) liked the idea of adding the DFSP to the user's address
• But for some institutions (e.g. Lehigh, Simmons etc), it wasn't clear whether the proposed solution would work
• I have since met with folks from Lehigh, Simmons, U of A and FLO and have received input from 5C by email
• I'll summarize the output of the conversations and present a new design proposal: https://docs.google.com/presentation/d/1FIzV1P7va_3yX0oLE7XauGPLZHA05NTOFutto_QNybg/edit#slide=id.g8f2aaa41d7_1_5 (begins slide 22)

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. 

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.

• This UXPROD feature has existed for a while and may or may not have been intended to support this need:https://issues.folio.org/browse/UXPROD-1561 If it is intended to support this need, it probably needs a bit of redesign.
• There are other ways this need to could be met. Fore example, Brooks suggested, "In a system with a lot of pickup locations, having a pickup location exclude list vs. a list of allowed pickup locations would probably be easier to set up/manage where the goal is to exclude just the item-local locations."
• I've prepped a short deck for us to review: https://docs.google.com/presentation/d/1WsYzZmIn5uX5ZBSVbgOUUa_huRXgFw5-QIZ80NeXTbo/edit
• Let's decide on whether we should modify UXPROD-1561 or if we should create a new UXPROD feature for this and gather SME thoughts on how this might be designed.

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.

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.)

• Because...
• Because...

Fast add records without barcodes:

• There are use cases for fast adds without barcodes (e.g. electronic resources like pdfs on a shared drive for course reserves)
• So we should not require a barcode
• Also, usually when creating fast add from checkout, you will have the item and barcode in hand so you can just scan 
• That said, for testing it would be really nice if the barcode would auto-populate into the item barcode field in check out app (assuming you have created from checkout). This wouldn't cause problems in real-life workflows, either, as it would just mean you didn't need to scan the barcode.
• We can use toasts or other messages to indicate to the user whether the barcode has been pasted into the field or not (if we are pasting into the field as opposed to copying to clipboard, it will be obvious anyway so messaging might not be important)

• People liked the hybrid solution in the deck
• People thought that specifying the alternate DFSP in the service point would be best as it allowed for most flexibility

• No decision on preferred option from deck
• Will form a small group to discuss further as it's quite complicated