Loans
(UXPROD-788)
|
|
| Status: | Closed |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None | Parent: | Loans |
| Type: | New Feature | Priority: | TBD |
| Reporter: | Darcy Branchini | Assignee: | Cheryl Malmborg |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | check-in, loans, post-v1, resourceaccess | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Epic Link: | Loans |
| Analysis Estimate: | Very Small (VS) < 1 day |
| Analysis Estimator: | Darcy Branchini |
| Front End Estimate: | Small < 3 days |
| Front End Estimator: | Jakub Skoczen |
| Back End Estimate: | Very Small (VS) < 1 day |
| Back End Estimator: | Jakub Skoczen |
| Development Team: | Prokopovych |
| Kiwi Planning Points (DO NOT CHANGE): | 1 |
| PO Rank: | 23 |
| Rank: Chalmers (Impl Aut 2019): | R4 |
| Rank: Chicago (MVP Sum 2020): | R5 |
| Rank: Cornell (Full Sum 2021): | R4 |
| Rank: Duke (Full Sum 2021): | R5 |
| Rank: 5Colleges (Full Jul 2021): | R4 |
| Rank: FLO (MVP Sum 2020): | R4 |
| Rank: GBV (MVP Sum 2020): | R4 |
| Rank: hbz (TBD): | R4 |
| Rank: Hungary (MVP End 2020): | R1 |
| Rank: Lehigh (MVP Summer 2020): | R4 |
| Rank: Leipzig (Full TBD): | R4 |
| Rank: MO State (MVP June 2020): | R5 |
| Rank: TAMU (MVP Jan 2021): | R2 |
| Rank: U of AL (MVP Oct 2020): | R4 |
| Description |
|
Not to be confused with backdating items as they are being checked in. This feature only refers to changing the date or time an item was returned after it has been checked in. This is triggered through the ellipsis menu on a row within the table display. https://drive.google.com/file/d/1fH7bq1TTcKy2woK28WcwY981_k00KIjG/view?usp=sharing |
| Comments |
| Comment by Tania Fersenheim [ 28/Jun/18 ] |
|
Changed UAL ranking to 4 at the request of patty.wanninger |
| Comment by Emma Boettcher [ 28/Jun/18 ] |
|
Updated Chicago to 5 after an update to the feature prioritization spreadsheet. |
| Comment by Erin Nettifee [ 20/Mar/19 ] |
|
This seems like something that could cause a lot of problems with history / audit trails. What would happen if changing a date/time of a return then meant that a fine on someone's record shouldn't have been charged? If the reason to do this is error correction, I think the better approach is to fix the impact of the error (e.g., waive an erroneously applied fine) then to add a feature that might cause doubt as to when/where an item was last touched. |
| Comment by Brooks Travis [ 14/Apr/21 ] |
|
I'm with Khalilah Gambrell here. It seems like a good idea at first blush, but probably just better to fix the effect. |
| Comment by Cheryl Malmborg [ 07/Dec/21 ] |
|
Ranked very low. There are also audit trail implications. |