/
Checking items out from the Central tenant

Checking items out from the Central tenant

Problem statement

Currently, items that have not been requested from the Central tenant cannot be checked out from the Central tenant. They must be checked out from the data tenant in which they are located. We need to allow all items, regardless of location or whether they have been requested or not, to be checked out from the Central tenant.

Related information

Requirements and Expectations

  1. There should be an ability to perform a check-out of an item in the Central Tenant without a prior request.

  2. In the Central Tenant, the history and statistics of check-outs are maintained in relation to the patron records.

Architectural design

Proposed solution

NOTE - The solution described below is only possible for ECS installations where all tenants are effectively parts/branches of one library. It is not applicable for ECS installations where tenants are separate libraries. In this case, checkout should be supported via requesting using DCB workflow.

In the Check Out UI App, the user scans the patron's barcode and then the item's barcode. During this process, the Check Out UI App communicates with the mod-circulation-bff module (instead of mod-circulation as it currently does).

The mod-circulation-bff module provides the /check-out-by-barcode endpoint (similar to mod-circulation). When processing a request to this endpoint, the module determines where to route this request further:

if a request associated is found in the current tenant { route to /circulation/check-out-by-barcode in current tenant } else if (ecsTlrFeatureEnabled && ecsCheckOutWithouthRequestingEnabled) { route to /mod-tlr/check-out-by-barcode in current tenant } else { fail }

Here ecsTlrFeatureEnabled is an existing flag that determines whether the ESC TLR feature is enabled, and ecsCheckOutWithouthRequestingEnabled is a new flag for managing new functionality of check-out in ECS without a prior request.

The mod-tlr module provides the /check-out-by-barcode endpoint and effectively implements a new, separate process:

  • Create a new type of transaction in mod-tlr

  • Make circulation item in Central Tenant

  • Create patron/patron group in the data tenant

  • Perform a check-out on the item in the data tenant, create a Loan, and then perform a check-out on the circulation item in the Central Tenant, creating a second Loan (both actions must be performed atomically, meaning if the second loan fails to be created for any reason, the first loan should be closed). The statuses of the item and circulation item need to change from Available to Checked Out.

…

Return workflow

Will there be any differences from the usual process when returning an item?

Assuming that during the check-in in the return workflow in each of the participating tenants (central and data), there is one item (actual item or circulation item) and one loan each, this process aligns with this https://folio-org.atlassian.net/browse/CIRC-2231 and does not require additional efforts.

Scope

  • ui-checkout - to change the endpoint being called

  • mod-circulation-bff - implement the logic branching (depending on the conditions, determine whether it is necessary to continue the checkout in the current tenant, or to run new logic in mod-tlr)

  • mod-tlr - implement a new, separate process orchestrated in mod-tlr that provides checkout in the Central/borrowing tenant

Analyzed alternatives

  1. If an item has to be checked out for internal library use the staff patron can switch affiliation to the required tenant and perform check out there

    1. Known issue: Shadow user records do not have barcodes which creates an error when trying to check out materials - materials cannot be checked out

  2. Proxying the checkout to the data tenant with minimal involvement of the Central tenant. We scan the item barcode, do not find the item, so we go to mod-search, find the required data tenant, go there, check the item status is Available, create a record of the patron/patron group in the data tenant in needed, and call check-out-by-barcode in the data tenant. Patron groups are shared, so they can be used in circ rules in the data tenant. Pros: This option is extremely simple, almost like a single-tenant checkout. Cons: However, in this case, there are no traces left in the Central tenant - no loans, no entries in the circulation log, it is not possible to track the number of simultaneously open loans, and it is difficult to see the whole picture completely.