Important Upgrade Considerations
This section outlines all changes that require special consideration for customers in production. Configuration changes may be needed to prevent operational interruptions. See checklist for guidelines on how to fill this out.
Changes and Required Actions
|Functional Area||Change or Addition||Considerations|
|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.|
Include issue link for bug fix, story or feature that applies
|Okapi||Upgrade Okapi to latest 4.14.x version|
When upgrading upgrade Okapi to the latest 4.14.x version, at least 4.14.10.
v4.14.9 has a bug that sometimes closes the HTTP connection before the response has been sent.
Versions before v4.14.8 have a Hazelcast vulnerability: https://nvd.nist.gov/vuln/detail/CVE-2022-36437
|Data Import & Inventory|
Update to the default MARC Bib-to-Inventory Instance MAP:
If you would like to review the mapping change first, go to https://github.com/folio-org/mod-source-record-manager/blob/master/mod-source-record-manager-server/src/main/resources/rules/marc_bib_rules.json and search for 590. Review that section of the rules, and then if that handling is wanted for a particular library tenant, add that section to their equivalent map.
After upgrade, library may want to review their local default MARC Bib-to-Inventory Instance map, and decide if they want to add this revised mapping into it.
Follow the instruction to update the rules.
|Data Import||Reminder when upgrading||When upgrading from one flower release to the next, confirm that the deployed modules are of compatible modules and are in the same release. If incompatible modules versions, Kafka messages consumed by older versions of modules can cause problems. When entity schema changes in such a way it usually leads to an API version bump and if module that requires a specific version of the API deployed and the API is not there - it results in an error. Unfortunately, there is no such mechanism for changes in Kafka message payload - topics that are used are the same, therefore a consumer in an older module version will consume the messages.|
|Settings, Circulation, Loan history||The circulation setting "Loan history" as been updated to "Loan anonymization"||Please note: The permission names have not been updated, and still refer to "Loan history"||N/A||N/A|
|Permissions, Circulation||With the permission "Settings (Circ): Can view loan history", the Save button on the Loan anonymization page is no longer visible (UICIRC-767).|
In addition, a new permission has been created, "Settings (Circ): Can edit loan history", for which the Save button on the Loan anonymization page is visible and can be selected (UICIRC-766).
|Please note: The permission names contain the old name of the setting (Loan history), but refer to the circulation setting Loan anonymization.||Update your users' permissions and/or permission sets, as required.||N/A|
Permission ui-tenant-settings.settings.enabled - display name "Settings (Tenant): View" has been made invisible
The permission is used to grant basic view to Settings > Tenant but grants no other functionality. It implies that you can use it to give view-only access to content in that area, which is not the case. Making the permission visible: false removes that confusion.
Recommend removing "Settings (Tenant): View" from any users prior to upgrading to Nolana.
You can also remove the permissions after upgrade by enabling Settings > Developer > Configuration > List invisible permissions in add perm menus and then editing the relevant user records.
Update your users' permissions and/or permission sets, as required.
Recommend removing "Settings (Tenant): View" from any users prior to upgrading to Nolana.
Actual cost will not be fully implemented for Nolana. It is recommended that you wait until Orchid to start using actual cost.
If you start using actual cost in Nolana, the “Lost items requiring actual cost” processing page will not be available for billing. This means that you will need to bill actual cost via a manual fee/fine that will NOT change Item status from “Declared lost”/”Aged to lost” to “Lost and paid” when the fee is paid.
If you started using actual cost in Nolana, when Orchid is implemented you will need to you will need to mark items as “do not bill” on the “Lost items requiring actual cost” processing page if fee was billed manually. The "Lost item fee policy" includes a setting For lost items not charged a fee/fine, close the loan after <interval>. Using this setting to "expire" actual cost lost items will eliminate the need for this if you set the <interval> to a smaller time period.
For details about when various actual cost functions will be available, see slide deck
|Resource Access||Improvements to Settings > Calendar|
The interface for adding, editing, or removing calendars from service points has significant UI improvements and has changed to a tabular UI format. Additionally, calendars can now be assigned to multiple service points and exceptions can store multiple openings and closures.
|All calendar-related permissions have changed may need to be updated.|
Permissions provided by ui-calendar 7.x have been updated to more specific ones; most notably, this includes the ".all" permission. Administrators may want to go through user's permissions and re-evaluate what is necessary with these new specific permissions.
The database schema used for mod-calendar has been overhauled, however, no special action is required. As part of the upgrade from 1.15.0, all existing data will be transformed and preserved. If you are not already on mod-calendar 1.15.0, we recommend upgrading to it before upgrading. Be sure you are upgrading to the latest version 2.3.1 as previous versions would migrate certain exceptional situations incorrectly.
We recommend going through the calendars post-migration and ensuring that all exceptions transferred as expected; exceptions that were not fully contained within a calendar (for example, calendar 01-01-2022 to 12-31-2022 and exception 12-25-2022 through 01-02-2023) may result in a calendar shown as an "Orphaned exception" in the interface or, if there are multiple exceptions/calendars for a date, it may not be transferred at all. System administrators can also search through the container logs for more information about what exceptions were associated with which calendars (which will display error messages if any exceptions were orphaned or dropped).
After the migration, institutions may desire to clean out historic calendars (this was impossible in the previous interface); this can be easily accomplished with the new purge feature.
|Data export - Export authority records||New default job-profile for authorities was added.|
Use MARC authority app
|It requires to load reference for module.|
|Locations||Locations and location units moved from reference data to sample data|
When initially enabling mod-inventory-storage for a tenant a few locations and location units (institutions, campuses, libraries) can automatically be created. Before Nolana loadReference=true triggered this, from Nolana on loadSample=true is needed.
Adjust scripts that expects them as reference data.
|Search||Routing was changed to default. All indexes should be recreated.||During the upgrade process|
mod-search indices will need to recreate for both instance and authority as described here
|Search||When using AWS OpenSearch, the response returned by the bulk api is malformed which is causing errors in mod-search. The issue does not occur with local instances of OpenSearch or ElasticSearch, only instances in AWS Infrastructure. Due to this, performance gains could not be determined. When the issue is resolved by AWS, this can be revisited.|
During the upgrade process before reindexing
Set environment variable INDEXING_DATA_FORMAT = json
Mapping rules were changed. It's required to update default mapping rules in the database.
|Only applies to a library that has MARC authority records in Morning Glory environment|
Apply after mod-source-record-manager upgrade. Please do the following actions.
|Fees/Fines||The buttons (e.g. Pay, Waive, Transfer) on the top of the Fees/Fines History and Fee/Fine Details pages have been replaced with an ACTIONS menu. This has been done so that the pages match the design of the rest of FOLIO. The functionality has not changed.|
|Inventory single record import/quickMarc derive||DB Read/Write split should be disabled for mod-source-record-manager||In case Read instance is not synchronising fast enough, some single record operations could fail||When mod-source-record-manager is deployed do not pass the environment variables for DB_HOST_READER and DB_PORT_READER (it won't be enabled by default)|
|Data Import||Settings and Configuration||Refer to Settings and Configuration page for details on modules involved in Data Import. Adjust if needed to optimise performance.|
|NCIP||Settings and Configuration||New optional configuration. Default value if not set: FOLIO|
|SMTP configuration||SMTP configuration was moved from mod-configuration to mod-email||Interesting information for FOLIO SysAdmins|
|Bulk Edit||Additional environment variables to back-end module deployment||This module uses separate storage of temporary (local) files for its work. These files are necessary for processing bulk-edit business flows. Any S3-compatible storage (AWS S3, Minio Server) supported by the Minio Client can be used as such storage. Thus, in addition to the AWS configuration of the permanent storage, one needs to configure the environment settings for temporary files storage||For mod-data-export-worker, add LOCAL environment variables discussed here: https://github.com/folio-org/mod-data-export-worker#environment-variables otherwise Bulk Edit file uploads will fail in Folio.|
|Data Import||Provided script to clean up Job profiles in case linked Mapping or Action profiles were edited||Editing Mapping or Action profiles already linked to a Job profile result in increased profile size (unnecessary elements are stored), which may lead to slow performance of mod-data-import-converter-storage, Kafka errors during DI process and excessive memory consumption by mod-source-record-manager||Follow the instructions at point 11 - Scripts for Inventory, Source Record Storage, and Data Import Cleanup|
|SRM, Data Import||Default limit for retrieving settings for mapping during DI is set to 1000.|
If library contains more data in the specified settings override the property "srm.mapping.parameters.settings.limit" (default=1000) when mod-source-record-manager is deployed.
|Permissions, OAI PMH, Vufind, EDS||Add permission oai-pmh.records.collection.get to edgeuser/service account||Post-upgrade, update your users' permissions and/or permission sets, as required with oai-pmh.records.collection.get. You will need to be able to view invisible permissions, config in Folio UI at Settings - Developer - Configuration. Once added, restart the edge-oai-pmh module(s)||Jason Root|
|App||New Permissions||Deprecated Permissions||Product Owner|
|Dashboard||Dashboard: Dashboard Administrator|
|Bulk edit||Bulk edit: In app - Update user records|
|App||Known issue||Workaround||JIRA issue||Product Owner|
|Users||Mail notices do not get sent to proxy, even when that value is selected, but get sent to sponsor||Currently no work around; this is new work to do the back-end of what is visible in the UI.||Julie Bickle|
|mod-inventory-storage||Authorities update through quick-marc are applied to mod-search records with a delay of 1 update||Remove ||MODINVSTOR-1006||Khalilah Gambrell|
Files generated by following jobs are available only for several hours due to AWS Identity and Access Management (IAM) instance profile settings:
|Repeat exports again||Magda Zacharska|
|Bulk edit||Intermittent error "Something went wrong" after rearranging columns while editing holdings record. The error occurs on the Are you sure form before any changes are committed.||Restart bulk edit.|
|mod-search||boundWith flag is not updated in mod-search||For mod-search either remove |
|Title level requests||No known workarounds.||, CIRC-1684, CIRC-1693||Stephanie Buck|
|Purging a tenant||After disabling modules with purge option for one tenant other tenants get this error:|
This affectes only modules where environment variable DB_MAXSHAREDPOOLSIZE is set.
|After disabling modules with purge option restart all modules where environment variable DB_MAXSHAREDPOOLSIZE is set.||Julian Ladisch|
- RMB-348Getting issue details... STATUS was implemented to split reading and writing traffics into separate database nodes. While it's working for some workflows (check in/out, MARC BIB/Authority Data import Creates and Updates), it is buggy in other workflows. These are: Acquisition, Data Export, Data Import of MARC Holdings.
Additionally in very rare circumstances when a failover happens between the database nodes, such as when the write node fails over to the read node (the read node now becomes the new write node and vice versa), the storage modules may still cache the old addresses so they may continue to write to what is now the new read node or that the old write node has gone out of service).
A workaround for the failover issue is to create an AWS lambda (or some process that listens for failover events) that restarts the RMB storage modules to create new connections to the new database nodes
|NCIP||When the acceptItem service is called, if the pickupLocation contains '/' the service will fail:||Use the patched version of the module:|
|ERM||When you view a License in the License App that has a linked Agreement, on viewing the "Agreements linked to this license" the Agreement information does not display (only the 'License link status' displays)||Currently no work around; the issue is fixed in mod-agreements 5.5.x||Owen Stephens|
Additional known issues
|Key||Summary||T||Updated||Potential Workaround||Development Team||Status||Resolution||Release|
Notes on functionality
PO Release Presentations
|Presentation||Presentation date||Presenter||SIG meeting (link)||Notes|
|Acquisitions||November 1, 2022||Dennis Bridges||Agenda and Meeting Notes#:~:text=Demo%20Nolana%20Release%20highlights|
|ERM: Agreements||November 2, 2022||Owen Stephens|
|View slide 2-4, and recording from 10:14-37:10 (includes Dashboard 13:45-17:45)|
|Dashboard||November 2, 2022||Owen Stephens|
|View slide 2, and recording from 13:45-17:45|
|Bulk edit||November 10, 2022||Magda Zacharska||Bulk edit related recording starts at 26:20|
Hot fix release #1 - RELEASED AT APRIL 20
Critical Service Patch #2- RELEASED AT 25 JULY
|Key||Summary||P||CSP Request Details||CSP Approved||CSP Rejection Details||Development Team|
|Total Unique Issues:||3||8||2||1||14|
View in Jira
Nonfunctional Requirements (NFR) Features
All Closed Bugs and Stories
Remaining Open Bugs at Time of Release
Assuming the FOLIO support policy remains unchanged, Nolana will be supported with critical security and bug fixes until Poppy (R2 2023) release (around November 2023). With the Nolana release Lotus has reached end of life and is no longer supported.