DCB loan policy flexibility based on library/agency code

Some libraries want different loan rules for items going to/from a specific library. Currently, all virtual items contain an effective location of “DCB”. Using a different data element than a location based data element (e.g. material types or loan type or patron type or any other) is not a viable means of solution.

Borrower loans for virtual items supplied by a specific library must use a circulation rule that is different than other members. The associated loan period should be set in the borrower library and the supplying library.

Circulation rules must be configured in the borrower library and corresponding circulation rules in the supplying library such that the supplying library loan period supports the special relationship between the two organizations.

Although MOBIUS has only two such library, the solution should be extensible to the use case for pickup anywhere AND for additional special relationships (whether one-to-one or one-to-many relationships).

Functional Requirements

As described in prod ticket: https://folio-org.atlassian.net/browse/UXPROD-5115

Non-Functional Requirements

[TBD]

Key aspects of the solution:

• Fill manually/automatically locations for all tenants in a consortia

• Create manually/automatically related loan policies

• Pass location to mod-circulation during the creation of a request/loan and allow the proper policy to be applied

• review all dependencies of DCB location with 000 code

Consortium structure

• The DCB service point will be assigned to a real or virtual location to keep the existing flows.

• Real and virtual locations must be pre-populated after or during the consortia tenant initialization.

• Add locationCode to the DCB API contract.

• Find the effective location ID by this code and pass it to mod-circulaton-item

• mod-dcb should be able to store a configuration (single unit) per tenant to connect to OpenRS Hub:
  
  

• The configuration is optional, and if disabled, mod-dcb will populate only locations for DCB (hardcoded values)

• Based on locationCode mod-dcb should be able to identify shadow location ID and populate it for mod-circulation-item

• An effective location is always set to the DCB location; it should be adjusted to the point at a location identified by locationCode

• Uses a lending library to code to populate the institution; it can be replaced with the real institution name, if it is found by location

  .put("effectiveLocationInstitution", item.isDcbItem() ? item.getLendingLibraryCode() : location.getInstitutionName())

• Check that shadow locations are not used

• Uses hard-coded DCB_LOCATION_ID, which should be checked if it affects circulation for TLR

• Virtual locations and location units should be marked (adding shadow flag)

• The user should not be able to modify these locations from UI (based on shadow flag)

• Forbid items from being assigned to these locations

• UI should show only non-shadow locations

• Shadow location should be only returned when the flag: includeShadowLocations is passed

1. The solution requires the creation of all locations of a consortium inside each FOLIO tenant.

   1. Tim Auger: Yes, please. That would simplify the effort on behalf of the customer if each library unique agency location

2. The solution requires the creation of related policies in FOLIO for each of the locations created in #1

   1. Tim Auger: No. This can be created manually by the customer.

3. The solution might overlap with functionality introduced by Vega and mod-tlr (check!)

4. How many real locations are expected per consortium deployment?
   Expecting ~3600 locations (tenants), the biggest deployment is ~100 locations

5. How often are locations updated in DCB-Hub? Should the periodic pulling of data be considered?
   New locations are added not frequently (once a week, once every few months)
   Probably, it should be done on demand, and each tenant in the consortium must receive a request to update the locations list when a new tenant is added to DCB-Hub