Requests (UXPROD-790)

[UXPROD-1561] Allow Request Policy to Control Request Fulfillment Options Created: 06/Mar/19  Updated: 17/Sep/23

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

Type: New Feature Priority: TBD
Reporter: Cate Boerema (Inactive) Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: requests, requires-discussion, round_iv
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File image-2019-03-06-11-37-42-094.png     PNG File image-2019-03-06-11-37-53-061.png     PNG File image-2019-03-06-11-39-16-515.png     PNG File image-2019-03-06-11-40-07-119.png    
Issue links:
Relates
relates to UXPROD-2689 Enable Request Policy to Determine Al... Closed
relates to UXPROD-113 Fulfilling delivery requests Closed
relates to UXPROD-2690 Prevent Local Page Requests Draft
Potential Workaround: Cate Boerema: Simplest solution would be to rely on the flag on the user record that says whether a given user can have items delivered or not (see draft mockup here: https://drive.google.com/drive/folders/1lqjdblpO_3wFLYcZdR4jabGCmp0iFsmC) This is less sophisticated than using request policy which looks at user as well as the item, but it might be sufficient for mvp.
Epic Link: Requests
Front End Estimate: Large < 10 days
Front End Estimator: Cate Boerema (Inactive)
Front-End Confidence factor: Low
Back End Estimate: XL < 15 days
Back End Estimator: Cate Boerema (Inactive)
Estimation Notes and Assumptions: CB: Per discussion with the cap planning team, some of use non-developers are estimating features to avoid disrupting development. I will tag this as "swag" so we know to come back and revisit later when we have more info and are closer to development.
Development Team: Vega
Kiwi Planning Points (DO NOT CHANGE): 16
PO Rank: 28
PO Ranking Note: 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): R4
Rank: Chicago (MVP Sum 2020): R4
Rank: Cornell (Full Sum 2021): R4
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R4
Rank: FLO (MVP Sum 2020): R4
Rank: GBV (MVP Sum 2020): R4
Rank: Grand Valley (Full Sum 2021): R2
Rank: hbz (TBD): R4
Rank: Hungary (MVP End 2020): R4
Rank: Lehigh (MVP Summer 2020): R4
Rank: MO State (MVP June 2020): R1
Rank: TAMU (MVP Jan 2021): R1
Rank: U of AL (MVP Oct 2020): R4

 Description   

The first version of the request policy only allows you to specify what types of requests are allowed for the requester/item combination.

This feature is about adding a section to the request policy to control fulfillment options. Current thinking on design of this section:

Old mockup of full blown request policy (for context): https://drive.google.com/drive/folders/12lN1MV7MZPU2NicldGC-y6orGgY_mR5v



 Comments   
Comment by Siska [ 19/Mar/19 ]

We are only interested in setting a default Hold shelf expiration date for all branches and policies. Do we still need this? We do not need delivery options since we only provide pick up.

Comment by Theodor Tolstoy (One-Group.se) [ 23/Apr/19 ]

Cate Boerema see Siska's comment

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

Hi Siska and Theodor Tolstoy (One-Group.se), it is already possible to set a default hold expiration period for each service point. Sounds like you don't need more than that, so the ability to override that in the request policy would not be needed for Chalmers.

The ability so specify fulfillment options would be nice for Chalmers, if only so you could specify that delivery is never allowed. That would eliminate the possibility that someone would accidentally set up a delivery request.

Does that make sense?

Comment by Siska [ 20/May/19 ]

Cate Boerema Since we will create our requests in EDS that will hopefully not be a problem either way

Comment by Cate Boerema (Inactive) [ 21/May/19 ]

Oh, that's right. You just wouldn't allow patrons to choose the delivery option through EDS. So, yeah, it doesn't seem like you need any of this Siska

Comment by Erin Nettifee [ 11/Sep/19 ]

The label of "receiving" is incorrect on this, I think - this is not related to acquisitions receiving, but patron fulfillment.

Comment by Erin Nettifee [ 24/Sep/20 ]

This is part of the workaround review sheet - and already being discussed with RA - but the workaround described is not sufficient for large library or consortial needs. There is a slack group (#request-policy) that has been discussing how this might develop. For Duke, the workaround is not sufficient.

Comment by Holly Mistlebauer [ 07/Mar/22 ]

This feature is marked DRAFT until Brooks Travis has a chance to review it for validity.

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