Loans (UXPROD-788)

[UXPROD-249] Check-in: Change date/time actions for an item returned Created: 21/Feb/18  Updated: 07/Dec/21  Resolved: 07/Dec/21

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.

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