Sunflower (R1 2025) Changes and required actions
Functional Area | Change or Additions | Considerations | Action timing, | Comments | Contact person, |
|---|---|---|---|---|---|
Affected app or module | What has been changed or added that should be noted for this release | What challenges may arise related to this change or addition | 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? | Name of user leaving comment: comment on what you encountered or ask a question @mention Contact person | User name of person that can provide additional detail. |
Folio Core / Platform | Introduction of Eureka | Several User and SysOps-facing changes | During upgrade prep, Upgrade, and post-upgrade | See https://folio-org.atlassian.net/wiki/spaces/REL/pages/991526914 | See https://folio-org.atlassian.net/wiki/spaces/REL/pages/991526914 |
mod-organizations | Integration type added for “Claiming” | Prior to Sunflower, integration type is undefined and assumed to be Ordering | During the upgrade, existing integrations should have “Ordering” added as “Integration type”. |
| @Joseph Reimers |
mod-users-keycloak/mod-consortia-keycloak | Enable the feature to allow users created in member tenants to log in to ECS. | Prior to Sunflower, only users created in the central tenant were able to log in in Eureka. The feature to enable login for users from member tenants should be enabled by making modifications to the following two modules:
| When adding a tenant to the consortium, all existing users and Keycloak identity providers (IDPs) are automatically created or upgraded to enable login functionality. If the tenant was already added to the consortium previously, it is necessary to invoke the following endpoints:
| More details about new migration is presented in this Confluence page: https://folio-org.atlassian.net/wiki/spaces/FOLIJET/pages/906297394 | @Serhii_Nosko https://folio-org.atlassian.net/browse/RANCHER-2125 (Refer to the related PR in the story to see how the feature was enabled for Rancher-based environments)
|
mod-organizations-storage/mod-invoice-storage | Add Kafka related env variables for these 2 modules | Starting with Sunflower, these two modules began sending Kafka events to support the Audit Events History functionality, which will be consumed by mod-audit | Add Kafka-related environment variables like KAFKA_HOST, KAFKA_PORT with the same values as those used for mod-orders-storage, where the audit events functionality was implemented prior to the Sunflower release |
| @Serhii_Nosko |
Authorities | Changes to MARC-Authority mappings were introduced | MARC migration for authorities must be executed with | After upgrading to new module versions |
| @Pavlo Smahin |
Instances | Changes to OpenSearch index mappings | Instance re-index is required to be executed according to instructions: https://github.com/folio-org/mod-search/tree/v5.0.7?tab=readme-ov-file#indexing-of-instance-records | After upgrading to new module versions |
| @Pavlo Smahin |
Agreements file storage |
| The new environment variable GLOBAL_S3_SECRET_KEY can be used to set an S3 secret key, used by the module when configured to use S3 for document storage (see https://folio-org.atlassian.net/wiki/spaces/FOLIOtips/pages/5673711 for more information on this configuration) Using this environment overrides the “S3 secret key” setting in the app and so can be used to avoid exposing the secret key in the FOLIO Settings UI | The “GLOBAL_S3_SECRET_KEY” environment variable should be set if it is preferred to make the secret key inaccessible via the FOLIO UI. This can be done at any time. |
| @Owen Stephens |
Licenses file storage |
| The new environment variable GLOBAL_S3_SECRET_KEY can be used to set an S3 secret key, used by the module when configured to use S3 for document storage (see https://folio-org.atlassian.net/wiki/spaces/FOLIOtips/pages/5673711 for more information on this configuration) Using this environment overrides the “S3 secret key” setting in the app and so can be used to avoid exposing the secret key in the FOLIO Settings UI | The “GLOBAL_S3_SECRET_KEY” environment variable should be set if it is preferred to make the secret key inaccessible via the FOLIO UI. This can be done at any time. |
| @Owen Stephens |
Agreements Local KB | New boolean environment variable SYNC_PACKAGES_VIA_HARVEST. Defaults to | This environment variable controls whether when using the Harvest method to get data from an external KB (specifically GOKb) whether packages are initially treated as “synchronising” ( For “paused” packages the harvester will not update the package title list (PCIs) for the package. For “synchronising” packages, the package title list will be updated. | The variable can be set at any time. The default behaviour will be observed if the variable is not set.
| Changing the variable will only affect packages that are first harvested after the variable has been changed (i.e. does not affect existing packages) | @Owen Stephens |
Grails based modules (mod-agreements, mod-licenses, mod-service-interaction, mod-serials-management) | Bump to Grails OKAPI version to resolve issue with federated locks during module upgrade/activation | n/a | It should be possible to remove any local mitigation/processes put in place around Grails modules to deal with the previous issue of federated locks having to be cleared | Previously federated locks could get ‘stuck’ during upgrades/activation and then need to be manually cleared In Sunflower this has been resolved. For a full description see https://folio-org.atlassian.net/browse/ERM-3662 Versions with the fix included in Sunflower R1-2025 release:
| @Owen Stephens @Ethan Freestone |
Search |
| Set |
| It will prevent index creation with unexpected mappings because Index creation should be allowed only explicitly via mod-search (during re-index or enabling module for tenant) | https://folio-org.atlassian.net/browse/RANCHER-2189 |
Circulation | New boolean environment variable ENABLE_FLOATING_COLLECTIONS; defaults to | To allow items to shift (“float”) between different locations depending on check-in location, this environment variable must be present and set to | The variable can be set at any time. |
| @Charlotte Whitt @Niels Erik Nielsen |
Inventory, SRS, Data import | Default MARC-Instance mapping rules were updated to add mapping for instance “deleted“ field |
| After upgrade, follow the instructions to update the mapping rules. |
| @Ryan Taylor |
Circulation, Requests, Pick slip printing | New use of Setting > Circulation > Requests > View print details > Enable view print details (Print slips) | To allow printing of Pick slips, “Setting > Circulation > Requests > View print details > Enable view print details (Print slips)” must be enabled | When upgrading to S CSP #1, in order to print Pick slips in the Requests app:
| Note: Related to CIRC-2416. This change will impact S CSP #1 - S CSP #3. | @Anne Ekblad @Alexander Kurash |
ECS Users (Eureka) | As of CSP 5, shadow users are automatically migrated |
|
| Prior to CSP 5, when upgrading Okapi ECS to Eureka ECS, shadow users were not automatically migrated. This has been resolved. | @Dennis Bridges |
mod-entities-link | For existing member tenants that have missing Authority shadow copies. | Without authority data in member tenant instance-authority link propagation will be broken and reports exported from member tenant may miss data. | First query shows the count of missing authority shadow copies in the member tenant. If the result is “0”, it means there are no missing shadow copies for this member tenant, and there is no need to run the following two scripts. | Only in consortium environment for a member tenant | Issue: https://folio-org.atlassian.net/browse/MODELINKS-374 @Svitlana Kovalova @Khalilah Gambrell |
mod-specifications | Change API default to false for the following endpoints
| This is a global change. |
| This is a global change and if a library wants catalogers to be warned of undefined fields/indicators/subfields then they will need to change these endpoints to true. | https://folio-org.atlassian.net/browse/MRSPECS-196 @Khalilah Gambrell |
mod-users, ui-users | As part of the Sunflower release, FOLIO introduces a new system-level custom field named | Important: Do not delete this fieldAlthough this field is created using the standard Custom Fields framework, it must not be deleted. | No action required unless field is deleted.
Note: In an upcoming FOLIO release, this field will be hidden from the Custom Fields UI to prevent accidental deletion and ensure consistent behavior across ECS-enabled installations. | If the field is deletedA migration script is available to repair affected environments by restoring the Hosting providers should run this script immediately if the field is deleted, or if tenants report broken login or shadow-user synchronization issues. | @Dennis Bridges |