Poppy (R2 2023) Release Notes

When can the action be taken (before, during or after upgrade)?

If applicable, detail what action(s) must be taken here

Is this action required for the next release?

If using Amazon S3: Only an officially supported Amazon S3 endpoint URL is allowed in the S3 URL environment variables of modules. Example:

Wrong: AWS_URL=https://s3-us-west-2.amazonaws.com
Correct: AWS_URL=https://s3.us-west-2.amazonaws.com

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.

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.

1. When not provided or provided with a wildcard * character, all tenants are legacy token tenants.

2. When provided, with a comma separated list of tenant ids, only those tenants will be legacy token tenants.
3. 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.

Libraries should review and decide: 

1. If existing Instances should be refreshed against the updated map, so that all existing instances reflect these changes

See Update of mapping to correct handling of repeated classification fields and subfields for additional details.

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

Default MARC-Instance mapping updated to adjust punctuation handling for the 1xx/7xx contributor fields and for the $e/$j relator terms

If the library wants more name relator terms to be standardized, for searching and filtering, this update will help.

Libraries should review and decide: 

1. If existing Instances should be refreshed against the updated map, so that all existing instances reflect these changes

See Update of mapping to adjust punctuation handling for 1xx/7xx contributors and $e/$j relator terms for additional details.

Follow the 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

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 first reminder is scheduled at check-out based on the due date and the reminder fee configuration defined in this section. As the first reminder is sent the next reminder is scheduled according to this configuration, and so forth. A timed process is then defined in mod-circulation, to pick up due reminders, charge fees and send notices.

If the library does not use reminder fees then leave this section unfilled.

A new timed process is defined in mod-circulation to process reminders that have become due according to the configured reminder fees policy.

By default the process is scheduled to run once a day, at one minute past midnight in Central European timezone (00:01 CET) where it will pick up reminders that have become due since the most recent run.

The default timing of the process can be changed using Okapi's timer interface. Use Okapi's timer API to find the timed process at path "/circulation/scheduled-digital-reminders-processing" and follow the Okapi guide to set the desired timing of the process.

The process can be disabled entirely, if desired by tenants not using reminder fees. The Okapi guide describes how to disable a timed process as well. This is not required though, since simply letting the process run will have negligible impact on installations that do not use reminder fees.

Requests, Request policies, Service points

• 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.

Loan-related notes/comments (action based):

Two new buttons for adding this information is now available from the detailed loan display, and the check-out screen when clicking the three dots.

The notes/comments are searchable in the Circulation log app. 

A new token supporting sending patron notices with the new patron information has been developed: 

{{loan.additionalInfo}}

7 new tokens for users primary address information supporting sending printed letters with a final reminder to patrons:

{{user.primarydeliveryAddressType}}

{{user.primaryAddressLine1}}

{{user.primaryAddressLine2}}

{{user.primaryCity}}

{{user.primaryStateProvRegion}}

{{user.primaryZipPostalCode}}

{{user.primaryCountry}}

Patron notices

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.

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

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. 

Mandatory change:

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. 

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).

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:

{
"id": "{id}",
"module": "OAIPMH",
"configName": "technical",
"enabled": true,
"value": "{\"enableValidation\":\"false\",\"formattedOutput\":\"false\",\"srsClientIdleTimeoutSec\":\"20\",

\"maxRecordsPerResponse\":\"50\",\"srsHttpRequestRetryAttempts\":\"50\",\"fetchingChunkSize\":\"5000\",

\"cleanErrorsInterval\":\"30\"}"
}

Requests metadata table should be empty or clean up in case there are records before upgrading.

When the "Anonymize all loans" button is clicked a confirmation modal will now appear before the anonymization takes place. 

UXPROD-3906

Amelia Sutton 

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.

The keyword search in the Users app will now match on a user's middle name. Therefore Users keyword search now matches on:

• username
• personal.firstName
• personal.preferredFirstName
• personal.lastName
• personal.middleName
• personal.email
• barcode
• id
• externalSystemId
• customFields with the "Text Field" or "Text Area" custom field types

Migration needed to correct call-number shelving order that is used for call-number browse:

• recalculate based on call-number type specified in a record
• recalculate for NLM and SuDoc call-numbers

2-action script: before and after upgrade

Instructions provided on the page: Call-numbers migration

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.

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.

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).

With the addition of two major new features (support for Metadb and pre-authored reports), the LDP app is now renamed Reporting. This reflects its ability to provide near-real-time information based on complex pre-authored reports.

The Reporting App is now compatible with Metadb.

1. Migration script for existed authorities could be found on the page: Authorities migration
2. Upgrading mod-entities-links and mod-inventory-storage have to be done in one Okapi install request.

Reindex for instance records are required.

mod-search reindex endpoint was updated (now it is possible to change index settings. Check MSEARCH-436 and MSEARCH-437 for details.

When can the action be taken (before, during or after upgrade)?

If applicable, detail what action(s) must be taken here

Is this action required for the next release?

A new tenant initialization parameter, "centralTenantId," is introduced to specify the tenant for database structure and index creation. This parameter is necessary because Elasticsearch indices and the database schema should only be generated for the central tenant. If the parameter is omitted, the tenant is assumed to be "not in consortia," and the indices and database schema are created. If the parameter is provided and it differs from the tenant for which the module is enabled, the tenant is considered a "member," and the indices and database structure are not generated.

This parameter is exclusively required for consortium-like environments and should be provided to all tenants within the consortium, both central and member tenants.

If the cluster has existing users - all they should be processed by the consortium pipeline: Steps to setup Consortia env.  The process of adding tenants to the consortium will take care about migration of existing users that have a type that does not equal to 'patron' or 'dcb'.

For Forgot email/Forgot password functionality make sure that config entries for module 'USERSBL' like: 'FOLIO_HOST', 'RESET_PASSWORD_UI_PATH' populated for each tenant in the consortium. So no new params added, just make sure that all existing ones are populated for each tenant.

For mod-authtoken to be able to do cross tenant requests for ECS based envs need to populate system property: 'allow.cross.tenant.requests=true'