Requests (UXPROD-790)

[UXPROD-4] Assign Patron default service point for requests and general customer service Created: 09/Jan/18  Updated: 16/Sep/20  Resolved: 11/Sep/19

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Requests

Type: New Feature Priority: P3
Reporter: Cate Boerema (Inactive) Assignee: Cate Boerema (Inactive)
Resolution: Duplicate Votes: 0
Labels: migration-load, requests
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Blocks
is blocked by UXPROD-269 CRUD service points Closed
Duplicate
duplicates UXPROD-113 Fulfilling delivery requests Closed
Relates
relates to UXPROD-784 Users App In Progress
relates to UXPROD-850 Migration Tools Open
Potential Workaround: Cate Boerema: Ask patrons to select a pickup service point with each patron-initiated request. When staff are creating requests in FOLIO, they will need to ask the requester which service point they want to pick up at and select it. Chicago has somehow implemented default service points for patrons directly in discovery

Note: default pickup service point isn't the only use for this information. When there is an issue with a patron, RA staff sometimes look to see what SP is their default. If it's in a different library, they might call the library and say "hey there's an issue with your patron". There is no real workaround for this use case.
Epic Link: Requests
Analysis Estimator: Khalilah Gambrell
Front End Estimate: Small < 3 days
Front End Estimator: Jakub Skoczen
Back End Estimate: Small < 3 days
Back End Estimator: Jakub Skoczen
Development Team: Prokopovych
PO Rank: 95.8
PO Ranking Note: 2019-07-18: Decreasing PO rank slightly per discussion with SIG to put this under Requests overdue/missing in transit feature and Patron notes on Requests
2019-07-12: Keeping PO rank same as calculated rank (with potential minor adjustments to avoid having two features with same rank)
Rank: Chalmers (Impl Aut 2019): R5
Rank: Chicago (MVP Sum 2020): R1
Rank: Cornell (Full Sum 2021): R1
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R4
Rank: FLO (MVP Sum 2020): R1
Rank: GBV (MVP Sum 2020): R2
Rank: hbz (TBD): R1
Rank: Hungary (MVP End 2020): R1
Rank: Lehigh (MVP Summer 2020): R2
Rank: Leipzig (Full TBD): R1
Rank: TAMU (MVP Jan 2021): R1
Rank: U of AL (MVP Oct 2020): R2

 Description   

Currently, when patrons request materials, the default pickup service point for the request is the first one in the dropdown menu. This means that, when patrons are creating their own requests through discovery, they need to find their preferred service point in the menu and select it each time (a minor hassle). That said, when a library staff member is creating the request on behalf or a patron, they may not even know which service point to select for the patron.

To solve this problem, new requests should auto-populate with the preferred pickup service point for the requester. It should be possible to override the default, when desired.

This feature used to be called "User branch/location" but, upon discussion with the RA SIG, the primary use of associating a patron with any type of location information would be to assign a service point as the patron’s default pick-up location for requests. Given that, we have renamed this feature "Assign Patron default pick-up service point for requests) and moved it to the Requests epic.

Current thinking on design (needs review with SIGs): https://drive.google.com/drive/folders/1lqjdblpO_3wFLYcZdR4jabGCmp0iFsmC



 Comments   
Comment by Cate Boerema (Inactive) [ 16/Apr/18 ]

Whoops - I thought this was my feature and I updated the description. Turns out it is actually assigned to you, Khalilah Gambrell. I don't think I removed anything important. I just added a few notes which I think will provide context for the next UM/RA SIG discussion on this.

Comment by Cate Boerema (Inactive) [ 11/Sep/18 ]

Update. We have implemented service points for user records, but I think the are different than the user branch/location referenced in this feature. The idea here, as I recall, is that you would be able to specify a main location for a user (higher level e.g. campus). I don't think it was expected to be functional (other than filtering users). I haven't discussed this with the RA or UM SIGs in ages, though, so I don't know how valid this requirement still is or what the priority might be.

Comment by Emma Boettcher [ 20/Sep/18 ]

Moved this from the User Management app to the Requests app based on email with Khalilah Gambrell and Cate Boerema and discussion in the RA SIG: patrons need to be associated with service points so that they have default pick-up location for requests.

Comment by Khalilah Gambrell [ 20/Sep/18 ]

Emma Boettcher - is it okay to update the title of this feature to Assign Patron default pick-up location for requests?

Comment by Emma Boettcher [ 20/Sep/18 ]

Khalilah Gambrell Sure, just did!

Comment by Cate Boerema (Inactive) [ 28/Sep/18 ]

And I just updated the description to reflect the current thinking.

Comment by Karen Newbery [ 26/Mar/19 ]

Does the user record have a place to store a default location?

Comment by Anya [ 29/Mar/19 ]

Comment from the March meeting: This is not very clear ...

Comment by Cate Boerema (Inactive) [ 25/Apr/19 ]

Does the user record have a place to store a default location?

Karen Newbery not yet. Adding that would be part of this feature.

Comment from the March meeting: This is not very clear ...

Anya what's not clear? This is about making it possible to specify a default pickup service point for requests for each patron. There would be a field in the user record and that selection in that field would drive the default in the Pickup service point menu in the request creation form (when that user is the requester).

Comment by Uschi Klute [ 12/Jul/19 ]

However, the desired pick-up counter must not be completely freely selectable. For older collections, which may only be issued in a certain reading room, it must not be possible to select a normal lending desk. The item-specific assignment to a service point should always have priority.

Comment by Erin Nettifee [ 17/Jul/19 ]

W/regards to workaround, UM today is discussing the use of statistical fields to do departmental mapping - depending on whether that happens, a library may be able to get a department on a record that could provide some basic info. It's going to end up being a library-by-library consideration.

Comment by Cate Boerema (Inactive) [ 11/Sep/19 ]

However, the desired pick-up counter must not be completely freely selectable. For older collections, which may only be issued in a certain reading room, it must not be possible to select a normal lending desk. The item-specific assignment to a service point should always have priority.

Uschi Klute I don't recall this requirement coming up in the RA SIG. If important, please reach out to Andrea Loigman to get on the SIG agenda.

I am going to close this feature as we will be addressing this functionality as part of the Delivery request feature ( UXPROD-113 Closed ). See UIU-1155 Closed and UIREQ-312 Closed for details and mockups.

Comment by Erin Nettifee [ 11/Sep/19 ]

Hi Cate Boerema - there is a requirement as far as I understood that we be able to limit where items can be delivered to - which I think is a bit of what Uschi is getting at. Uschi - does https://folio-org.atlassian.net/browse/UXPROD-1561 get at what you're talking about?

Comment by Uschi Klute [ 11/Sep/19 ]

Cate Boerema & Erin Nettifee - I suppose that the request policy can refer to a specific location. In the mockup (https://folio-org.atlassian.net/browse/UXPROD-1561) I see that I will be able to select/determine the Service Points for picking up an item from a certain location. Then everything's fine.

Comment by Erin Nettifee [ 11/Sep/19 ]

Right - just note that that feature did not make cap-mvp. I know we sent feedback in that we really need the pickup list, but I'm not sure where that feedback is in consideration.

Generated at Fri Feb 09 00:05:06 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.