Bulk Edit
(UXPROD-868)
|
|
| 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: |
|
||||||||||||||||
| Issue links: |
|
||||||||||||||||
| 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 1. List of supported identifiers:
2. List of displayed columns by default: (as on User's Loan details)
3. List of additional columns to be displayed
4. The associated loan action should be dueDateChange? or bulkDueDateChange? How this value is being used in Folio? Out of scope
Use case(s)
Additional use cases: https://folio-org.atlassian.net/wiki/display/BULKEDIT/Bulk+Edit+Use+Cases Questions
Additional information: |
| Comments |
| Comment by Erin Nettifee [ 23/Sep/22 ] |
Yes, this is for the checkout service point, the ID for that should be on the loan record.
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.
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.)
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.
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
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.
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.
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.
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 (
|
| Comment by Magda Zacharska [ 08/May/23 ] |
|
Moving LC1 label from epic to defining features with Caitlin Stewart permission. |