, thanks a lot!

Hi
I have added the analysis of this spike in the comments. Please take a look.

Thanks.

cc :

W.r.t

• Make virtual service point attribute “Hold shelf expiration period” configurable

I didn't start work the on it. But before starting the work, we need to discuss whether we need to have new api for maintaining the hold shelf expiration or we can use the env variable to pass the value for every tenant.

UXPROD-5005 - Updating a Virtual Patron’s Group via Edge API

Current Behavior:
If a user already exists in FOLIO, the system uses the user data as-is without making any changes.

Expected Behavior:

• If the patron group in the incoming request differs from the patron group of the existing user, the system should update the patron group.

• This update should only be implemented for users with LENDER or PICKUP roles, as it applies exclusively to virtual users.

Note:
The patron group of real users should not be modified under any circumstances.

Implementation is almost done, may be few loggers can be added or some code refactoring can be done if needed and needs to be thoroughly tested

You can find the draft code changes here

UXPROD-5054 - Support DCB Requests on Unavailable Items

Current Behavior:
Currently, a Page request is always created in the LENDER role, assuming the item's status is always available. mod-circ will throw error if the item status is not available

Expected Behavior:
Before creating a request in the LENDER role, the item's status must be checked:

• If the item status is Available, create a Page request.

• If the item status is Checked out, Paged, In transit, Awaiting pickup, or Awaiting delivery, create a Hold request.

• For all other statuses, throw an exception.

Implementation Progress:
The above changes have been implemented, but the flow has not been fully tested. Multiple test cases are required for the same role:

1. Flow 1: Create a transaction when the item status is Available and complete the status transition as per the state transition diagram.

2. Flow 2: Create a transaction when the item already has one or more requests (resulting in a Hold request) and complete the status transition as per the state transition diagram.

Anticipated Issue:
Consider a scenario where an item is checked out already(Item status will be Checked out in this case) and a transaction is created. The transaction status will be set to Created. If the patron later returns the item, the existing loan will close, triggering an event (as the system listens for loan events in the LENDER role). There is a possibility that the code could update the transaction status from Created to Closed, which is not the expected behavior.

Proposed Solution:
Currently, when a loan event is received, the transaction is fetched based on itemId and a transactionStatus that is not Closed. For the LENDER role, an additional check needs to be added before updating the transaction status. Specifically, ensure that the transaction status is not Created before making the status change.

This solution needs thorough testing to ensure that it does not introduce other issues or unexpected behavior.

You can find the draft code change below, this doesnt have the fix of the above mentioned issue