Requests
(UXPROD-790)
|
|
| Status: | Draft |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None | Parent: | Requests |
| Type: | New Feature | Priority: | P4 |
| Reporter: | Cate Boerema (Inactive) | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | delegate_candidate, requests, round_iv | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Epic Link: | Requests |
| Front End Estimate: | Medium < 5 days |
| Front End Estimator: | Michal Kuklis |
| Front-End Confidence factor: | Medium |
| Back End Estimate: | Medium < 5 days |
| Back End Estimator: | Marc Johnson |
| Estimation Notes and Assumptions: | Assumes that some extension of the check in API might be needed to support this |
| Development Team: | Vega |
| Kiwi Planning Points (DO NOT CHANGE): | 1 |
| PO Rank: | 54 |
| PO Ranking Note: | 2020-10-20: Lowering PO rank to equal the calculated total rank, as I have confirmation that this is not needed for remote storage integration
2020-10-05: Bumping up the PO rank, as I believe this may be needed for remote storage circulation (to signal that something needs to be routed home to remote storage). If it turns out to not be needed for that purpose, I will lower ranking. 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): | R4 |
| Rank: Cornell (Full Sum 2021): | R4 |
| 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: Grand Valley (Full Sum 2021): | R1 |
| Rank: hbz (TBD): | R2 |
| Rank: Hungary (MVP End 2020): | R1 |
| Rank: Lehigh (MVP Summer 2020): | R4 |
| Rank: Leipzig (Full TBD): | R1 |
| Rank: MO State (MVP June 2020): | R3 |
| Rank: TAMU (MVP Jan 2021): | R2 |
| Rank: U of AL (MVP Oct 2020): | R2 |
| Description |
|
There are (at least) two scenarios in which a checked in item needs to go in transit:
FOLIO displays a modal popup at check in under these scenarios. We had initially intended to have two slightly different popups for the scenarios but the development needed to make that possible was complex so we decided to start with a single, generic "in transit" modal. Original two different modal popups:
Current generic popup: https://drive.google.com/drive/folders/1G31thPxXT1CogRQIGALxNr5jkOgwhyyi The purpose of this feature is to implement two different modal popups. Some institutions need the distinction to be visible in the modal, as they have different workflows (e.g. requests are expedited). Out of scope: Ability to customize the modal text |
| Comments |
| Comment by Cate Boerema (Inactive) [ 15/May/19 ] |
|
Marc Johnson and Michal Kuklis could you please provide estimates for this feature when you have a moment? |
| Comment by Marc Johnson [ 16/May/19 ] |
|
Cate Boerema Do you have a sense for how the system should determining what purpose the transit is for? Does only the presence of a request that is in transit mean that the modal should be for pickup? |
| Comment by Cate Boerema (Inactive) [ 20/May/19 ] |
Yes, at the moment, that would be the only scenario where the modal should be for pickup (at the moment). |
| Comment by Holly Mistlebauer [ 07/Mar/22 ] |
|
This feature is marked DRAFT until Brooks Travis has a chance to review it for validity. |