Requests
(UXPROD-790)
|
|
| 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: |
|
||||||||||||||||
| Issue links: |
|
||||||||||||||||
| 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. |