Loans
(UXPROD-788)
|
|
| Status: | Draft |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None | Parent: | Loans |
| Type: | New Feature | Priority: | TBD |
| Reporter: | Erin Nettifee | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | bulk-edit-loans, enettifee-reviewed | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||
| Epic Link: | Loans | ||||||||||||
| Development Team: | Vega | ||||||||||||
| PO Rank: | 0 | ||||||||||||
| Rank: Cornell (Full Sum 2021): | R2 | ||||||||||||
| Description |
|
Current situation or problem: Libraries need the ability to batch renew large numbers of loans at a time, including loans for more than one user at a time. This is different than desired functionality for automatic renewal -
This is also different than functionality for a bulk change of due date (supported in scripting shared in the community) in that some libraries would want to do a batch renewal rather than change due date so that items with limited renewals fail to get a new due date, as expected according to the loan policy. In scope
Out of scope
Use case(s)
Proposed solution/stories Links to additional info Erin Nettifee added this feature to capture the use case for bulk renewals, which is something that Duke has had reason to have to do and continue to do going forward in FOLIO for some patron groups. Questions
|
| Comments |
| Comment by Thomas Trutt [ 14/Jul/22 ] |
|
If the API endpoint for the function was also available this would be a helpful function for discovery layers. Maybe the same function could be implemented in the user loan view to speed up renewals there as well. |
| Comment by Erin Nettifee [ 10/Aug/22 ] |
|
I believe pretty strongly that the bulk edit app should not handle things that are really bulk actions like this Magda Zacharska - down that road lies madness. Renewing loans isn't as simple as changing a due date on the record, you have to use the circulation rules, you have to be able to handle errors that appear. It's not clean and it really has the potential to make the bulk edit app much, much, much too complicated. |
| Comment by Thomas Trutt [ 26/Aug/22 ] |
|
Should this then be moved form Bulk edit over to part of one of the circulation modules? I feel this is a need not only for institutions that want to do bulk renewals from semester to semester but would also be useful for the current frontend and edge APIs to speed up renewal times. |
| Comment by Erin Nettifee [ 23/Sep/22 ] |
|
I am talking to the Circ POs about whether this should be part of the bulk edit app in addition to changing due dates. |
| Comment by Thomas Trutt [ 13/Mar/23 ] |
|
Erin Nettifee just looping around. Any word on if this will be in Bulk edit or should remain separate. I Still feel it is needed, but agree with your original concerns of this being in Bulk edit. |
| Comment by Erin Nettifee [ 13/Mar/23 ] |
|
There was not a firm consensus. The one piece of feedback was a sense that the project needed to be able to do bulk renewals in the way that UChicago has built outside of FOLIO but no one else felt as strongly as me that Bulk Edit shouldn't be the tool to do it. The issue I think is that if Bulk Edit repurposes the existing 1-1 APIs than we introduce additional performance concerns. We really need the functionality for bulk renewal APIs. |
| Comment by Thomas Trutt [ 13/Mar/23 ] |
|
In general i am on the same page as you when it comes to any circulation tasks is Bulk edit. I'm worried on multiple leaves; performance issues, not following circ rules / bypassing policies, etc. Im not framiler with how UChicago is doing this. |