Bulk Edit (UXPROD-868)

[UXPROD-3805] Bulk edit - loan due dates Created: 19/Sep/22  Updated: 24/Jan/24

Status: Draft
Project: UX Product
Components: None
Affects versions: None
Fix versions: Sunflower (R3 2024)
Parent: Bulk Edit

Type: New Feature Priority: P3
Reporter: Magda Zacharska Assignee: Magda Zacharska
Resolution: Unresolved Votes: 0
Labels: LC1, consortia-ebsco, firebird-po-share, loc, volaris-candidate
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File image-2022-09-23-07-12-07-965.png     PNG File screenshot-1.png    
Issue links:
Cloners
is cloned by UXPROD-3806 Bulk edit - request hold shelf expira... Draft
Relates
relates to CIRC-1626 Checkout allows "Change due date" to ... Closed
Release: Sunflower (R3 2024)
Epic Link: Bulk Edit
Front End Estimate: XL < 15 days
Front End Estimator: Magda Zacharska
Front-End Confidence factor: 20%
Back End Estimate: XXL < 30 days
Back End Estimator: Magda Zacharska
Back-End Confidence factor: 20%
Development Team: Volaris
PO Rank: 0
Rank: Cornell (Full Sum 2021): R3

 Description   

Current situation or problem

When the access to the library is restricted due to some unexpected events as sudden building repairs,  inclement weather or pandemic, the due dates on loaned materials need to be adjusted accordingly as patrons are prevented from returning loaned materials on time.  Currently in FOLIO, adjustments to the loan due date need to happen one by one.

In scope
Users are able to identify loans by submitting a list of identifiers, preview matched records, specify the change to the loan due date and review the confirmation after the bulk edit completes.  The flow should be the same as already implemented for users and item records in app approach.

1. List of supported identifiers:

  •   Loan uuid
  •   Users uuid
  •   Patron group
  •   Loan policy Id
  •   Location?
  •   Service point (checkout service point?)
  •   Item hrid, uuids, barcodes?

2. List of displayed columns by default: (as on User's Loan details)

  • Item title
  • Item status
  • Due date
  • Requests
  • Barcodes
  • Fees/fines incurred
  • Effective call number string
  • Renewal count 
  • Loan policy

3. List of additional columns to be displayed  

  • Contributors
  • Location
  • Loan date

4.  The associated  loan action should be dueDateChange?  or bulkDueDateChange?  How this value is being used in Folio?

Out of scope

  • loan and return dates
  • renewal date
  • building query - to be covered in UXPROD-3785 Closed

Use case(s)

  • Library closes for inclement weather and patrons cannot return their loaned material on time.
  • Library closes a  part of the building for necessary repairs
  • Library closes a part of the building due to mold outbreaks or flooding
  • Extending loans for next semester

Additional use cases: https://folio-org.atlassian.net/wiki/display/BULKEDIT/Bulk+Edit+Use+Cases

Questions

  1. Should the loan’s due date change be allowed for overdue loans?
  2. How should Recalls be handled in case of changed loan’s due date? What would be the impact on other request types?
  3. Any loan statuses should be prevented from their due date being updated?
  4. Any item statuses should prevent loan’s due date to be updated? (including declared lost, claimed returned, aged to lost?)
  5. What would be expected behavior when the entered data is invalid?
  6. What should be specified as a loan action and how this value is being used in FOLIO?
  7. How should the change in loan’s due date impact fees and fines?
  8. Would the change of the loan’s due date impact loan policies? If yes, how?

Additional information:
Loan details displayed on the User record:



 Comments   
Comment by Erin Nettifee [ 23/Sep/22 ]

Supported identifiers
Service point (checkout service point?)

Yes, this is for the checkout service point, the ID for that should be on the loan record.

Should the loan’s due date change be allowed for overdue loans?

Yes, there are use cases for this. An important thing to understand is that if an item is overdue, a fine is not actually charged until the item is returned. So changing the due date in the case an item is just overdue should not be an issue, I think. It's worth asking the SIG.

How should Recalls be handled in case of changed loan’s due date? What would be the impact on other request types?

We allow items that are recalled by another patron to have their due date changed right now, and I can think of cases where libraries would want the ability to do this (even if they would only do it in an emergency.)

It would have no impact on holds and it's not relevant to pages - if an item is paged, by definition there's no loan associated with it (it was on the shelf.)

Any loan statuses should be prevented from their due date being updated?

A closed loan should not be able to have its due date updated - there is too much potential at that point to screw with fee/fine records.

Any item statuses should prevent loan’s due date to be updated? (including declared lost, claimed returned, aged to lost?)

Definitely declared lost, aged to lost, claimed returned. I would also add any item status for which loans are not allowed even with override. See https://lotus.docs.folio.org/docs/platform-essentials/item-status/itemstatus/#currently-implemented-item-statuses

What would be expected behavior when the entered data is invalid?

The UI currently warns for a due date in the past, but allows it. Which, I guess there could be cases for it.

More concerning is that the UI allows you to change due dates to be before the initial check out, which would be very concerning to me because you could accidentally screw up a bunch of loans. So ideally it would stop you from doing that, but you'd have to do that loan by loan, since individual loans could all have different initial due dates, So not sure the right way to handle this.

What should be specified as a loan action and how this value is being used in FOLIO?

Loan actions are used in reporting and in the circ log, and I think they also display as the action on the loan record. So I guess the question to the SIG is how much it matters to see "due date changed" and "due date changed (bulk edit)" - I tend to think the more specific action isn't needed, but getting input would be good.

How should the change in loan’s due date impact fees and fines?

Holly should be consulted on this, particularly around the planned work to implement reminder fees for the German libraries, But basically, no open loan actually has an associated fee/fine until it is either returned. What I don't remember is if returning a loan that is overdue and generates a fine means the loan is closed, or still open..... I think it's closed at that point. So this might be related to the question above about loan statuses.

Would the change of the loan’s due date impact loan policies? If yes, how?

No - there's no dependency there. If you bulk changed a due date, and then later on the patron did a renewal, they might find different behavior because of the bulk due date change, but that's not relevant to this feature in my opinion.

Comment by Brooks Travis [ 27/Sep/22 ]

I'm going to disagree about preventing due date changes to a date prior to the loan date. There are operational use-cases where this may be needed functionality. That said, those could be accommodated if we also allowed back-dating loan dates during checkout via the UI. The APIs support this, but no option is presented to the operator.

Comment by Erin Nettifee [ 27/Sep/22 ]

If you're thinking about migration, I think that's different than bulk edit, because we're editing existing loans with bulk edit, and not creating records.

But maybe what we need is to add an additional field called "loanedOn" and check on that, rather than the record metadata date. Not sure.

I filed a bug ( CIRC-1626 Closed ) and I'll mention this over there.

Comment by Magda Zacharska [ 08/May/23 ]

Moving LC1 label from epic to defining features with Caitlin Stewart permission.

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