/
Applying Loan Policy from Data Tenant for ECS Requesting

Applying Loan Policy from Data Tenant for ECS Requesting

Problem statement

During the checkout of an ECS Request in the central tenant, the loan policy from the Central Tenant is applied; it is expected that the Loan Policy from the data tenant, which is more specific, should be applied.

Related information

Architectural design

Summary

Option 1 was chosen for implementation for the following reasons:

  • allows you to apply exactly the same loan policies that are selected in the data tenant when creating a loan in the Central tenant,

  • the scope of work is clear and the estimates are given by the development team with a high confidence level.

Solution option #1

Indeed, the problem is that requests are applying the rules from the data tenant, but checkouts are applying the rules and loan policies from the Central tenant. This manifests as follows: during checkout and loan creation in the Central tenant, the Loan Policy in the Central tenant is selected (say, 2 years). Meanwhile, when creating a corresponding loan in the data tenant, the Loan Policy from the data tenant, which is more specific (say, 30 days), is selected. This inconsistency prevents the correct handling of loans in the Central Tenant.

Note: this issue applies only to the Loan Policy; LOC does not use fees/fines, and the notice policy and request policy do not need to be adjusted.

The proposed solution involves copying the Loan Policy from the data tenant to the Central tenant for each request and enforcing this specific Loan Policy for the associated loan. The detailed steps are as follows:

  • Before checkout, determine the data tenant to which the item belongs.

  • Then, perform the calculation of circulation rules in this data tenant to determine the loan policy; the key point here is to perform a dry run, which does not execute an actual checkout.

  • Next, copy the identified Loan Policy into the Central tenant.

  • Then, perform the checkout and create a loan in the Central tenant to enforce the application of the previously copied Loan Policy.

  • Finally, perform the checkout in the data tenant.

This appears to be the most efficient way to implement a solution promptly. A more robust solution might include a synchronization mechanism for these policies, as well as a method to identify an original policy from its copies. However, these enhancements are not feasible within the immediately available timeframe.

Work Breakdown Structure and Estimates

Module

Scope

# from the diagram

Estimates, SP

Module

Scope

# from the diagram

Estimates, SP

ui-checkout

  • Change the /check-out-by-barcode endpoint from mod-circulation to mod-circulation-bff

#1

1

mod-circulation-bff

  • Add a new /check-out-by-barcode API endpoint, with the same parameters as in mod-circulation

  • Implement routing based on condition - if (ecsTlrFeatureEnabled && isTenantCentral), then call mod-tlr; otherwise, call local mod-circulation

#2

2

mod-tlr

  • Add a new endpoint (name it somehow)

  • Define the data tenant for the item from the checkout request (call mod-search by item’s barcode)

#3

3

  • Call mod-circulation in that data tenant to define a loan policy to be copied

  • Call mod-circulation-storage in that data tenant to retrieve a loan policy by UUID

  • Call mod-circulation-storage in the Central tenant to store this loan policy there

    • same UUID

    • add some prefix to the loan policy name to highlight it’s a copy

  • Call mod-circulation to perform check-out with forced loan policy

#4

2

mod-circulation

  • Add a new endpoint to dry-run circulation rules and return the selected loan policy (input parameters: item, patron group)

#5

2

  • Force check-out-by-barcode to use the specific loan policy by its UUID

    • add optional parameter “overrideLoanPolicy" with a loan policy UUID

    • if (overrideLoanPolicy) then force to use it somewhere

#6

2

As a result, we have estimates of 1 SP for FE + 11 SPs for BE work. For a team working on a task without prior experience in the circulation domain, the backend estimates should be increased by 1.5(?) times.

Known Limitations or Consequences

  • Ongoing synchronization of loan policies is not within the scope of the current solution. This means that the loan policy is copied when creating the loan, and if the original loan policy in the data tenant is changed, the copy of the loan policy in the Central Tenant remains unchanged.

  • The solution covers loan policies only; other types of policies (namely, request, patron notice, overdue fine, and lost item fee) are not considered. See Notes on functionality (Library of Congress features)

Solution option #2

One of the key reasons for the observed issue with the circulation rules, particularly with loan policies, is that the location setup is neither centrally managed nor synchronized between tenants. However, in mod-search, there is information about the location setups of all tenants, which is also maintained up to date.

Accordingly, the Circulation Rules Editor in the Central Tenant can be taught to work not only with the local Location setup but also with locations from other tenants. This would allow for a uniform configuration of circulation rules in both the Central and data tenants.

Furthermore, loan policies can be configured to ensure the desired behavior.

Work Breakdown Structure and Estimates

To accurately understand the scope and decomposition, spike tasks are needed:

  • BE spike - 2 SPs

  • FE spike - 3 SPs

Module

Scope

Estimates, SP

Module

Scope

Estimates, SP

Settings → Circulation → Circulation rules → Circulation rules editor

  • Be able to query mod-search for location setup (tenants, institutions, campuses, libraries, locations) instead of mod-inventory

  • Update the Circulation rules editor to display the selection of affiliation

 

mod-circulation

  • Update the rules validation during the saving

  • Use mod-search to retrieve the item’s tenant and effective location

  • Use mod-search to retrieve location setup by tenant ID and effective location

  • Tune org.folio.circulation.rules.Drools, org.folio.circulation.rules.CirculationRulesProcessor etc. to handle locations there

 

Known Limitations or Consequences

  • This option assumes that it's possible to configure the circulation rules and loan policies as required under the new conditions, including training staff to configure everything correctly and ensure consistency in case of changes to the rules or policies on any side. All this will need to be managed manually.

  • There is no "failsafe" mechanism; no check or stopper to prevent inconsistencies when a checkout is completed in one tenant (Central) - closing the request, creating a loan, changing the item - but fails in another tenant (data). A contingency plan is necessary to address these potential issues.

 

Comments