Requests
(UXPROD-790)
|
|
| Status: | Closed |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | Q4 2019 | Parent: | Requests |
| Type: | New Feature | Priority: | P3 |
| Reporter: | Cate Boerema (Inactive) | Assignee: | Cate Boerema (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | cap-mvp, po-mvp, requests | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||||||||||||||||||
| Potential Workaround: | Cate Boerema: Cancel and re-create requests in order that they should be fulfilled. This is not a good workaround if the institution has patron notices being sent to the requester when requests are created and/or cancelled. Getting these emails could be confusing to patron. | ||||||||||||||||||||||||||||||||||||
| Epic Link: | Requests | ||||||||||||||||||||||||||||||||||||
| Front End Estimate: | XL < 15 days | ||||||||||||||||||||||||||||||||||||
| Front End Estimator: | Michal Kuklis | ||||||||||||||||||||||||||||||||||||
| Front-End Confidence factor: | Low | ||||||||||||||||||||||||||||||||||||
| Back End Estimate: | XL < 15 days | ||||||||||||||||||||||||||||||||||||
| Back End Estimator: | Marc Johnson | ||||||||||||||||||||||||||||||||||||
| Estimation Notes and Assumptions: | Low confidence because I think there could be some complexity around how we handle whether only a single request swap is done at a time or whether multiple requests can be reordered together | ||||||||||||||||||||||||||||||||||||
| Development Team: | Prokopovych | ||||||||||||||||||||||||||||||||||||
| PO Rank: | 96.1 | ||||||||||||||||||||||||||||||||||||
| PO Ranking Note: | 2019-07-12: Increased priority a bit relative to calculated to put this higher than Assign Patron default pick-up service point for requests ( |
||||||||||||||||||||||||||||||||||||
| Rank: Chalmers (Impl Aut 2019): | R2 | ||||||||||||||||||||||||||||||||||||
| Rank: Chicago (MVP Sum 2020): | R2 | ||||||||||||||||||||||||||||||||||||
| Rank: Cornell (Full Sum 2021): | R1 | ||||||||||||||||||||||||||||||||||||
| Rank: Duke (Full Sum 2021): | R1 | ||||||||||||||||||||||||||||||||||||
| Rank: 5Colleges (Full Jul 2021): | R2 | ||||||||||||||||||||||||||||||||||||
| Rank: FLO (MVP Sum 2020): | R4 | ||||||||||||||||||||||||||||||||||||
| Rank: GBV (MVP Sum 2020): | R2 | ||||||||||||||||||||||||||||||||||||
| Rank: hbz (TBD): | R2 | ||||||||||||||||||||||||||||||||||||
| Rank: Hungary (MVP End 2020): | R1 | ||||||||||||||||||||||||||||||||||||
| Rank: Lehigh (MVP Summer 2020): | R1 | ||||||||||||||||||||||||||||||||||||
| Rank: Leipzig (Full TBD): | R1 | ||||||||||||||||||||||||||||||||||||
| Rank: TAMU (MVP Jan 2021): | R1 | ||||||||||||||||||||||||||||||||||||
| Rank: U of AL (MVP Oct 2020): | R4 | ||||||||||||||||||||||||||||||||||||
| Description |
|
The initial implementation of the Request queue (
Details (from SIG meeting)
Current mockup: https://drive.google.com/drive/folders/1ADrLDD09Ub9AKL7Vu704viS8EVPSB8xv
|
| Comments |
| Comment by Cate Boerema (Inactive) [ 12/Oct/18 ] |
|
This feature was split off from
Looks like we have the mockup and story for the dedicated request queue page but no mockups or stories for the ability to re-order. Marking this feature DRAFT. |
| Comment by Cate Boerema (Inactive) [ 25/Apr/19 ] |
|
The auto-ordering of recalls above holds really should happen prior to this feature. Marking blocked on
|
| Comment by Cate Boerema (Inactive) [ 15/May/19 ] |
|
Michal Kuklis and Marc Johnson can you please add tshirt estimates for this feature? Thanks much! |
| Comment by Cate Boerema (Inactive) [ 02/Jul/19 ] |
|
Discussed with the RA SIG during the feature re-ranking exercise. See discussion at 55:19 of https://drive.google.com/file/d/15RbACU90Ln4JAazWSz0iM4ZSYia6mIaK/view?usp=sharing
|
| Comment by David Bottorff [ 02/Jul/19 ] |
|
This is a rare enough occurrence at Chicago, with relatively few requests on a specific item, that we could live without it for up to 1 quarter by cancelling and then recreating requests as needed. |
| Comment by Cate Boerema (Inactive) [ 09/Jul/19 ] |
|
Follow up on above comment. I tested what currently happens when a recall is placed after a hold request.
So, under normal circumstances, the current borrower will get the recall notice and return the item quickly at which point it will be checked in and the hold request will begin fulfillment (since it's first in the queue). When that requester picks the item up, the loan period for the new loan will be shortened if the applied loan policy has made use of the "minimum guaranteed loan period for recalled items". When the item is subsequently returned, it will be checked in and the recall request will begin fulfillment. |
| Comment by Cate Boerema (Inactive) [ 26/Aug/19 ] |
|
Marking blocked as there are some design and priority questions. See
|