App | Notes | Jira | Product Owner |
|---|---|---|---|
Requests | In the central tenant, item barcode links in Request details will not work because the item is not located in the central tenant. | ||
Requests | Users can create, edit, and cancel a request. Users can reorder a request queue. Move and duplicate functionality is not included in this release. Note when placing a new Request: Requests can be placed in the Requests, Users and Mediated requests apps. In the future, we plan to implement requests from Inventory, as is available in single tenant environments now. We recommend copying and pasting barcodes into Requests as a workaround. | ||
Mediated requests | Authorized users can create, edit, decline, and confirm Mediated requests, as well as conduct Confirm item arrival and Send item in transit activities. Once a Mediated request is confirmed, a circulation Request is created and visible in the Requests app. Authorized staff will see Private patron data in the Secure tenant. | ||
Title level requests | Data tenants can manage their TLR settings, but cannot manage ECS TLR settings. All data tenants must enable TLR in order to utilize cross tenant requesting and circulation. | ||
Secure tenant | Secure tenant will contain Congressional patron data and is highly permissioned. Users actively affiliated with this tenant will see Private patron data, while Private patron data in other tenants will be obfuscated. | ||
Check out | Currently, items that have not been requested from the Central tenant cannot be checked out from the Central tenant.
| UXPROD-5072: ECS Support: Check out all items from Central/main tenant | |
Circulation | To enable cross tenant circulation, circulation rules need to be present in each tenant. | ||
Requests, Inventory records | Because item records reside in data tenants, when a Request is placed in the Central/Borrowing tenant, a temporary copy of the item record, called a shadow item record, is created. The shadow item record in the Central tenant will have differences from the item record in the Data tenant. The shadow item record in the Central tenant will show an Effective location of DCB, and once the requested and loaned item has been returned and checked in to the Central tenant, the item status will stay “Checked out” even though the loan is closed, and the physical item is in transit to it’s “on shelf” effective location. | ||
Circulation, Loan rules | When a loan policy is applied in the Central tenant, the policy will appear as COPY_OF_[loan policy name] from the lending tenant in Loan details. This indicated that a copy of the loan policy from the lending tenant was checked and applied in the Central tenant. |
The data tenant contains holdings, items, and its location setup. This means that you can develop detailed circulation rules for different locations and utilize patron groups, loan types, and material types. For example, in the screenshot below, Location-A and Location-B have different policy sets.
Loan/Request Rules must be strictly defined—the validation of these rules will determine the acceptance or rejection of a request.
No notification templates should be created there.
All materials in the Central Tenant are borrowed. All borrowed materials have an effective location “DCB”. Therefore, in the Central Tenant, you can build rules based on this:
s 000>000>000>000: <specify policies here> |
However, in the Central Tenant, it is currently not possible to determine from which collection/tenant the material was borrowed. Consequently, it’s not feasible to create separate rules for materials from, say, General Collections and the Asian Division.
Request policies must be permissive - essentially, allow everything for everyone. Loan policies don't matter because the original loan policies from the lending tenants are applied. Loan policies will appear in the Loan details as COPY_OF_[loan policy name], indicating the loan policy from the lending tenant was applied.
Notification templates must be created here as all patron records are available (except congressional ones).
The Secure Tenant stands apart because it contains not only its own materials (with its location setup) but borrowed materials as well. Therefore, in the Secure Tenant, locations can also be used to differentiate scenarios - DCB as the effective location for borrowed materials and real, effective locations for the oLoan collection.
Please note that the rules for borrowed materials should be maximally permissive, while those for owned materials should be strict and precise.
Another distinction of this tenant is that it also stores patron records. Consequently, for secure requests, it turns out that there are no patrons in the Central Tenant, so notifications are not sent from there. Thus, notifications must be configured separately in the Secure Tenant for congressional patrons.
When a user places a request in the ECS setup with mod-tlr enabled, FOLIO creates more than one request to perform the circulation. For most ECS requests, 2 records are created - one in the Central and one in the data tenant; for working with secure requests, a third record is added to them in the Secure tenant. These requests serve different purposes, so they're not identical:
in the Central Tenant, the request serves for tracking and notifications,
in the Data Tenant, the request is used to validate granulated rules and request/loan policies,
in the Secure tenant, the request serves to validate granular rules and request/loan policies, to send notifications to patrons (managed by this tenant), and to offer traceability to authorized staff.
The table below provides recommendations for configuring circulation rules and different types of policies for the LoC setup:
Policy / Tenant | Central tenant | Data tenant | Secure tenant |
|---|---|---|---|
Request policy | Reference Allow All request policy (or a custom policy that must allow NOT LESS than all request policies of all data tenants together) | Strictly defined tenant-specific request policies - validation of those rules will determine acceptance or rejection of a request as well as allowed service points |
|
Loan policy | It doesn't matter, because the original loan policies from the lending tenants are applied | Strictly defined tenant-specific loan policies - validation of those rules will determine the details of a loan |
|
Patron notice policy | Patron notice templates and policies must be created here for all the patrons except congressional ones | Reference Send No Notices notice policy | Patron notice templates and policies must be created here for the congressional patrons |
Overdue fine policy | Reference overdue policy | Reference overdue policy | Reference overdue policy |
Lost item fee policy | Reference lost item policy | Reference lost item policy | Reference lost item policy |
Note - all the reference policies mentioned above are created on FOLIO automatically as reference data:
Reference Allow All request policy - https://github.com/folio-org/mod-circulation-storage/blob/master/reference-data/request-policy-storage/request-policies/allow-all.json
Reference Send No Notices notice policy - https://github.com/folio-org/mod-circulation-storage/blob/master/reference-data/patron-notice-policy-storage/patron-notice-policies/basic-notice-policy.json
Reference overdue policy - https://github.com/folio-org/mod-feesfines/blob/master/reference-data/overdue-fines-policies/overdue-fine-policy.json
Reference lost item policy - https://github.com/folio-org/mod-feesfines/blob/master/reference-data/lost-item-fees-policies/lost-item-fee-policy.json