Spillover/refactor overrides for renewals - FE and BE

Current situation or problem: Overrides for patron blocks and item blocks at check out (UXPROD-2909) and requests (UXPROD-2910) was completed for Iris release. It included a refactoring of the code to handle several errors at check out or request with a single BE call and FE presentation, including patron blocks, items blocks, and other reasons that an item might be blocked from borrowing - some overridable and some not overridable. Renewal overrides (UXPROD-2911) were completed for the Iris release by "fitting it into the current code." The user experience is not ideal because patron blocks and item blocks are handled separately and multiple renewals is also not ideal and doesn't include an item block (maximum number of items already checked out set in loan policy – different than by patron group limits). We feel this should be improved to be consistent with the approach taken at check out - both BE and FE. We also left the old/previous override endpoints in place for both check out and requests so we need to remove those as part of our cleanup.

In scope: Refactor UX/UI and BE for renewals to be more consistent with check out functionality and clean up old override endpoints for check out and request.

Out of scope: Will not introduce new functionality.

Use case(s):

• As a user with permission to do a patron block and/or item block overrides, I want to be able to override a renewals that's being blocked – due to a patron block, item block (# of items checked out - loan policy) or another reason, such as loan policy/circ rules - non-loanable, number of renewals limit, etc.**

Proposed solution/stories:

• CIRC-1064
• More to come... one for return all errors, one for handling/displaying all errors and one for the actual override.

Questions