Module will fail on startup or when enabling a tenant if system user password is not set.
Consider setting a different SYSTEM_USER_NAME and a different SYSTEM_USER_PASSWORD for each module.
Before upgrade set environment variables/secure store variables.
The new password will be applied when migrating a tenant to the Poppy version of the module.
If changing the SYSTEM_USER_NAME from the default name or from the previous name the old system user still exists and must be manually disabled or deleted.
Refresh token support. Expiring token support. See the guide how to configure for more information.
Third party integrations that use non-expiring legacy tokens will need to be updated to use the new authn/login-with-expiry token endpoint during the deprecation period of Poppy and Quesnelia. Within Poppy and Quesnelia both the legacy authn/login and new login endpoints will be supported.
Integrations that use the edge API are unaffected.
System operators can configure access and refresh token expiration (TTLs) as documented in the mod-authtoken README using the new token.expiration.seconds system property.
It is also possible to configure the token cookie SameSite attribute using LOGIN_COOKIE_SAMESITE environment variable. as documented in the READMEs of mod-login and mod-login-saml.
When the LOGIN_COOKIE_SAMESITE attribute is not set, it defaults to the more restrictive Lax attribute.
System operators who wish to take full advantage of the enhanced security of expiring tokens, there is a new system property legacy.token.tenants in mod-authtoken. This property affects the system state in three ways.
When not provided or provided with a wildcard * character, all tenants are legacy token tenants.
When provided, with a comma separated list of tenant ids, only those tenants will be legacy token tenants.
When provided with an empty string value, no tenants will be legacy token tenants.
A legacy token tenant is a tenant for which a request to the legacy authn/login endpoint will not return a 404. See the readme of mod-authtoken for additional details.
Follow instructions here for updating third party integrations and for configuration.
In Poppy, backend and frontend modules default to using the new authn/login-with-expiry endpoint which issues expiring tokens. Enabling the legacy token endpoint through configuration does not disable this new endpoint. It only has the effect of exposing the legacy endpoint to requests for a given tenant allowing for a smother transition for clients which currently depend on the legacy endpoint.
Follow the instructions to update the mapping rules.
Mandatory change.
Note that any revised mappings will only apply to Instances created or updated via MARC Bibs after the map is updated. To refresh existing Instances against the current SRS MARC Bibs and current map, the library may consider running Script 3 described here: Scripts for Inventory, Source Record Storage, and Data Import Cleanup
Note that any revised mappings will only apply to Instances created or updated via MARC Bibs after the map is updated. To refresh existing Instances against the current SRS MARC Bibs and current map, the library may consider running Script 3 described here: Scripts for Inventory, Source Record Storage, and Data Import Cleanup
This functionality enables libraries to reliably process large MARC 21 files through data import. When enabled, the system automatically splits large files into smaller parts, which are optimal for processing.
The overdue policies has been extended with an additional section to define “Reminder fees”. The policy is defining the wanted process to bill reminder fees.
Reminder schedule. The process runs nightly and once per day. It creates the appropriate reminders for overdue items if an overdue policy with an active reminder fee section is in effect.
If the library do not use reminder fees then leave this section unfilled.
A new environmental variable INNREACH_TENANTS introduced which is mandatory and should contain the list of tenants for which mod-inn-reach module will be enabled.
The INNREACH_TENANTS variable is not set then the module will not start.
For each type of request allowed in a Request policy, libraries will be able to specify which Service points are allowed for pickup (from among the Service points that are flagged as pickup SPs in Settings > Tenant > Service points).
The New Request form will be dynamic, enabling Title / Item information AND Requester information to determine available Request types and Pickup locations
Libraries will see a confirmation popup when changing a Pickup location from “Yes” to “No” as a reminder that this action will remove it from existing Request policies and affect all Circulation rules using the policies.
Given: You have a lost item policy that charges the actual cost + a notice policy that sends notices with the existing trigger “Lost item fee(s), charged”, When: You bill the actual cost for an item that has aged to lost, Then: A notice is sent to the patron, according to the settings in the notice policy.
There are no new options or features in the notice policy or the notice templates; rather, the existing triggers have expanded their scope.
Please note: This ALSO works for items that have been declared lost.
Before upgrading to Poppy and/or switching to actual cost, please review whether your notice policies and/or templates (e.g. wording) need to or can be updated as a consequence.
Remember: Updates to a notice policy are applied when the open loan is next updated. Updates to the lost item policy are NOT applied to open loans.
Given: You have billed the actual cost for a lost item (both whether aged to lost or declared lost) + you have a notice policy that sends notices with the existing trigger “Lost item returned - fee(s) adjusted”, When: The lost item is checked in (returned), Then: A notice is sent to the patron, according to the settings in the notice policy.
There are no new options or features in the notice policy or the notice templates; rather, the existing triggers have expanded their scope.
Before upgrading to Poppy and/or switching to actual cost, please review whether your notice policies and/or templates (e.g. wording) need to or can be updated as a consequence.
Remember: Updates to a notice policy are applied when the open loan is next updated. Updates to the lost item policy are NOT applied to open loans
Lost item fees (set cost, actual cost and processing fee) can be bundled into one notice, overnight (or whenever you have agreed to with your hosting provider).
The functionality works the same as for notices trigged by the “Loan due date/time”:
There is a new “Mutliple fee/fine charges” token pair to add to the templates: #feeCharges & /feeCharges
For the triggering event “Lost item fee(s) charged”, there are two new options to select:
Send overnight with multiple lost item fee charges by patron. – This option will bundle any open lost item charges into one email (by standard, up to 100 charges). MUST contain the multiple charges tokens: #feeCharges & /feeCharges
Send throughout the day with one lost item fee charge per notice. – This represents existing functionality, and will be the default setting in your existing notice policies that use this trigger. MUST NOT contain the multiple charges tokens: #feeCharges & /feeCharges
Before upgrading to Poppy and/or selecting this option, please review whether your notice policies and/or templates (e.g. wording) need to or can be updated as a consequence.
Remember: Updates to a notice policy are applied when the open loan is next updated. Updates to the lost item policy are NOT applied to open loans.
Overdue fines can be bundled into one notice. The functionality is very similar as for check in and out notices:
There is a new “Mutliple fee/fine charges” token pair that MUST be added to the templates: #feeCharges & /feeCharges Otherwise, the notices will have an empty email body.
For the notice policy trigger “Overdue fine, returned”: The overdue fines generated in a single check in session are bundled when the check in session is closed.
For the notice policy trigger “Overdue fine, renewed”: The overdue fines are bundled when you renew multiple items at the same time.
Before upgrading to Poppy and/or selecting this option, you MUST update the relevant notice templates to include the multiple charges tokens. Otherwise, the notices will have an empty email body.
In addition, please review whether your notice policies and/or templates (e.g. wording) need to or can be updated as a consequence.
Remember: Updates to a notice policy are applied when the open loan is next updated. Updates to the lost item policy are NOT applied to open loans.
Addition: Institutions will now be able to choose to have title level request holds fail OR always succeed, following Circulation rules. (Through Orchid, holds can always be placed, regardless of Circulation rules).
Via discovery: The TLR endpoint used by edge-patron tries Page, Recall, then hold when TLR is enabled. If you allow recalls, by policy, it will never fall back to TLR hold (if holds are also allowed by policy).
Settings > Circulation > Title level requests. Select the box next to "Fail to create title level hold when request is blocked by circulation rule" to prevent holds from succeeding when Circulation rules do not allow them.
Additions: Actual cost, fee/fine, and status details have been added to the Actual cost processing page. You can now access the processing page through the Action menu on the User details record. An "X" has been added to enable people to leave the processing page without needing to use the back button on the browser.
New field completeUpdatedDate has been added to the instance schema to improve OAI-PMH performance for incremental harvests (with from/until parameters)
A new property cleanErrorsInterval has been added to OAI-PMH technical configuration. The property defines for how many days the error logs are stored.
1) Retrieve OAI-PMH technical config via request: GET /configurations/entries?query=module="OAIPMH" and configName="technical".
2) Update config: PUT /configurations/entries/{id} with body included parameter cleanErrorsInterval:
Added new accordion "Assigned users" when viewing a permission set in settings. If the logged in user has the "Users: Can view permissions assigned to users" permission, this accordion contains a table listing the name (Last name, First name) and patron group of each user who has the permission assigned.
If the logged in user has the "Users: Can assign and unassign permissions to users" permission assigned, a button will appear at the top of the accordion labeled "Assign/unassign" which will bring up a modal to search for users and assign or unassign them the selected permission set.
Increased memory requirements. Module descriptors updated to reflect these
In testing the latest release of mod-agreements is using slightly more memory. While it cannot be predicted how this will affect any particular environment it is recommended to review the updated module descriptors as per https://github.com/folio-org/mod-agreements/pull/684/files
Review available memory and MaxRAMPercentage used by mod-agreements
New configuration KBIngressType controls whether external knowledge base data is obtained through a harvesting/pull model (where mod-agreements fetches data from external systems) or through a push model (where an external system pushes data into mod-agreements via an API endpoint)
The application determines which KBIngressType is to be used through an environment variable: INGRESS_TYPE
This can have the values:
Harvest (Default and used is no INGRESS_TYPE environment variable is set)
PushKB
Although the KBIngressType can be set via the environment variable, it is not recommended that a running system is switched between services.
While the PushKB ingress type has been tested in the hosted-reference environments (snapshot and snapshot-2) it has not yet been tested in a more production like environment where larger data sets can be loaded and where the use of this process over a period of time can be monitored for any issues
This being the case it is not recommended that mod-agreements v6.x.x is used with
ingressType = KBIngressType.PushKB
in a production environment without first running extensive testing
No action is needed to keep the population of the Agreements Local KB from an external knowledge base operating as previously as the default services used in mod-agreements v6.x.x is Harvest which is the same method as previous versions of mod-agreements.
In either configuration file upload (JSON or KBART) in the Local KB Admin module can still be used in addition to integration with an external knowledge base
New titleInstanceResolverService available which uses work (rather than title) level IDs to match data from external sources to the local KB
The titleInstanceResolverService controls how resource data from external sources (added through external knowledge base integration, other system integrations or file upload). In mod-agreements v6.x.x a new service WorkSourceIdentifierTIRSImpl is added
The application determines which titleInstanceResolverService is to be used through an environment variable: TIRS
This can have the values:
IdFirst (Default and used is no TIRS environment variable is set)
WorkSourceIdentifier
TitleFirst
Although the titleInstanceResolverService can be set via the environment variable, it is not recommended that a running system is switched between services.
While the new WorkSourceIdentifier method has been tested in the hosted-reference environments (snapshot and snapshot-2) it has not yet been tested in a more production like environment where larger data sets can be loaded and especially in situations where the incoming data from external data sources interacts with existing data in the Agreements Local KB which may have been loaded from various sources
This being the case it is not recommended that mod-agreements v6.x.x is used with
TIRS = WorkSourceIdentifier
in a production environment without first running extensive testing
No action is needed to keep the population of the Agreements Local KB from an external knowledge base operating as previously as the default service used in mod-agreements v6.x.x is IdFirst which is the same method as previous versions of mod-agreements.
Whether it is being used or not introduction of the new WorkSourceIdentifierTIRSImpl method has resulted in a change to the processing of data added through file upload (JSON or KBART) in the Local KB Admin module.
New endpoints at edge-patron and mod-patron added that return available Pickup service points - This is a Discovery UX related enhancement (e.g., Locate and EDS).
(For ECS-enabeld environments) User type is a required field. For non-consortia environments, it is optional but can be used if desired through the UI.
In a consortia environment, users must be given a type of "patron" OR "staff". There is also a type of "system" and "shadow", "dcb" that is used by FOLIO to manage user accounts and access across members.
Can not be ignored when creating users as it will be required in ECS environments. In non-ECS environments selecting a value or leaving this field blank will have no consequence. If a value is set it will be possible to filter accounts based on this data.
Authorities, authority note types, authority source files, and the authority reindex API have been relocated from mod-inventory-storage to mod-entities-links. The implementation remains consistent with the previous version, including APIs and permissions. The database schema was changed.
Migration script for existed authorities could be found on the page: Authorities migration
Upgrading mod-entities-links and mod-inventory-storage have to be done in one Okapi install request.
We highly recommend running mod-fqm-manager with read/write split, using the standard read/write split configuration, in order to prevent the module from impacting the performance of other FOLIO modules
MODSOURCE-601 requires the execution of scripts to populate marc_indexers version data for existing records so that existing marc records can be matched/found using marc fields other than 001, 999f$s, and 999f$i.
Thescripts to populate marc_indexers versionshould be run after upgrading mod-source-record-storage from v5.6.7 (or lower) to v5.7.0. During the module upgrade from v5.6.7 (or lower) to v5.7.0 it is recommended to set property srs.record.matching.fallback-query.enable = true to enable the fallback query, ensuring the lookup of records imported prior to v5.6.8 until these scripts have been completed. After the scripts are completed, this property can be set to false (which is the default value) in order to avoid fallback query execution, as it will be redundant once the scripts are finished.
Request field fulfilmentPreference has been renamed to fulfillmentPreference
This is a breaking change. All third party integrations that use request related APIs (like /circulation/requests... or /request-storage/requests...) need to change the spelling of this field name accordingly.
Fallback credentials for mod-pubsub's system user have been removed from the code.
Before Poppy, libraries could use optional environment variables SYSTEM_USER_NAME and SYSTEM_USER_PASSWORD to override default user credentials. Now these variables become mandatory. If they are not present in the system, mod-pubsub will crash immediately after start.
Set environment variables SYSTEM_USER_NAME and SYSTEM_USER_PASSWORD (if they are not present) before upgrade.
To make mod-search consume all types of changes for instances, holdings, items, and changes related to bound-with functionality it has a consumer with a default Kafka topic pattern:
This pattern could be changed by setting KAFKA_EVENTS_CONSUMER_PATTERN environment variable.
If the library requires the default behavior of mod-search, please ensure that the KAFKA_EVENTS_CONSUMER_PATTERN is either omitted from the environment variables or is set to the same value as the default pattern.
