Problem statement

At present, it's not possible to check out a requested item to anyone other than the requester. Only the requester at the top of the queue is eligible to borrow the item. This can lead to problems in scenarios where, for instance, a requester pages an item, but another patron retrieves it from the stacks before circulation staff has a chance to move it to the hold shelf. In certain situations, it might be desirable to allow the non-requesting patron to check out the item nonetheless.

Related information

• UXPROD-5280: Override non-requester checkout (Analysis/Discovery)In Progress

• https://docs.folio.org/docs/access/check-out/checkout/

Analysis

The required behavior varies depending on the environment type and the request type. The table below summarizes this.

Notes

1. Simply changing the type of a request (e.g., Hold → Recall) in the database doesn't mean much, since the bulk of type-specific logic occurs during the creation of the request (incl. circulation rules, loan policy, due date, etc.)

2. Recall requests do not have any separate queue

3. ECS TLR support is the priority

Go back one step vs. Re-create

Re-create: We create a new request, the same as “the request that was unlucky and whose item was taken out of turn”, and put it in the same position

• Re-create all requests (1 or 2), create a new DCB transaction,

• and either stop at step 1 or go to step 2 on the DCB State Transition diagram

• correctly insert a new request in the same place where the previous request was before the check-out

Roll back a step

• change status(s) of all requests, DCB transactions, a circulation item, and an inventory item

Some of the logic may be related to the change in item status, and the consequences of check-out are difficult to predict.

Outstanding questions

1. If a patron who is given an item "out of turn" already has a request for this item/title somewhere further down the queue, what should be done with this request - delete it automatically, notify the librarian about it with a request to confirm the deletion, or leave it?

   1. AEE update after Team discussion (6/2/2025): Leave it. Possibly address in Phase 2 or 3.

2. Notifications - when and how? Can we use the exact same event/template as for the status Open - Not yet filled, or should a new, specific template be added/used here? (event - on Recall)

   1. We can use the exact same event/template as for the status Open - Not yet filled for phase 1. The libraries can add wording to the existing template that expresses something like, “If you are receiving this notice after you have already received one, then it could indicate that this Item has been given to another patron.”

   2. New trigger for “Suspend request” for phase 2 or 3.

3. What if the first request in the queue is the secure one (from the Secure tenant) - can this request be overridden?

   1. AEE update after discussion with TT (6/2/2025): For first pass: Yes, but consider adding link to first request back to Override popup. Possibly address in Phase 2 or 3.

4. What are the expectations for converting to a Recall type? Is it just a request status change? Do we need to recalculate the due date?

   1. AEE after discussion with TT (6/2/2025): If the first request is a Recall, leave the request status as Recall. Recalculate the Due date.

      1. System performs check out to non-requester and sets the due date on that check out based on current business logic for next request type (e.g., if next request is a Hold, it does nothing. If the next request is a Recall, modify the due date based on the Request policy.

5. Check-out - from the Central tenant only?

   1. We do not currently support check-out from the Central tenant without requesting - UXPROD-5072: ECS with mod-tlr Support: Check out all items from Central/main tenantDraft

   2. What happens if there’s an ECS TLR request, and someone is trying to check out an item without requesting it?

Proposed solution

1. If there is no request for an item, then there is nothing to override. Just create a request and do a checkout.

2. If there is a request for an item, and this request can be deleted during an override, then update this request (create a shadow user in the data tenant, update all entities associated with this with a new patron ID) and perform a checkout.

3. If there is a request for an item, and this request can NOT be deleted during an override, then - update this request (create a shadow user in the data tenant, update all entities associated with this with a new patron id), check out this already updated request, and create a new request for the original patron and place it to the top of the queue.

Pros:

• Simplicity - no need to roll back requests/transactions

• Addresses both ECS TLR and single-tenant cases

Notes:

• Check what the patron’s data is copied to requests (so that it needs to be updated)

• The original request will not be visible in the history of the original patron

• The Сirculation log won’t be updated (the decision/design (if needed) may be postponed to phase 2 or 3)

• For addressing the issue with recall, swap patrons, perform checkout, and create a loan, then create a new request (incl. Recall), put it on top of the queue

Additional info and Diagrams