Ramsons (R2 2024) 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. |
mod-search | Implement indexing for inventory locations |
| Locations reindex needed after the upgrade. | Under the hood when specifying resourceName=location the reindex for libraries, institutions and campuses will be started as well automatically. | @Viacheslav Kolesnyk , @Pavlo Smahin |
mod-inventory-storage | Holdings’ |
| Before upgrade, manual script must be run to address any holdings records with Source = null. If not run, then users may have difficulty updating Holdings records with Source = null. See mod-inventory-storage script instructions: https://folio-org.atlassian.net/wiki/spaces/REL/pages/105710298 | API major versions updated for
| @Viacheslav Poliakov (Unlicensed) , @Pavlo Smahin |
mod-inventory-storage | Instance’s |
| Async migration execution is required after the upgrade. Could work in the background. POST /inventory-storage/migrations/jobs
Body:
{
"migrations": [
"publicationPeriodMigration"
]
}To track status of migration execute the endpoint: GET /inventory-storage/migrations/jobs/<jobId>To validate that migration is finished SQL script could be executed: SELECT 1 FROM <tenant>_mod_inventory_storage.instance WHERE jsonb -> 'publicationPeriod' IS NOT NULL LIMIT 1;If nothing returned then migration was successful. | API major vers ions updated for
| @Pavlo Smahin |
Search, Inventory | 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: (${ENV}\.)(.*\.)inventory\.(instance|holdings-record|item|bound-with) | 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. |
|
| @Pavlo Smahin |
mod-search | New re-index process implemented for instance records. |
| Full re-index required. After the upgrade use new API to index instance records.
| Instructions can be found in: https://github.com/folio-org/mod-search/tree/v4.0.0?tab=readme-ov-file#indexing-of-instance-records | @Pavlo Smahin |
Inventory, SRS, Data import | Default MARC-Instance mapping rules were updated to add:
|
| After upgrade follow the instructions to update the mapping rules. |
| @Ryan Taylor, @Kateryna Senchenko |
MARC authority app |
| Requires use of MARC migration tool since authority mapping rules were updated. https://folio-org.atlassian.net/wiki/spaces/SPITFIRE/pages/492142594 |
| @Pavlo Smahin @Khalilah Gambrell | |
Automated patron blocks |
|
|
|
|
|
SIP2 | Setting Up SIP2 for Multiple Tenant-Specific Ports
|
| If any SIP2 customer (e.g. MeeScan) wants to use the feature of using multi tenant for specific port then below configurations settings can be applied https://github.com/folio-org/edge-sip2?tab=readme-ov-file#setting-up-sip2-for-multiple-tenant-specific-ports |
| @Gurleen Kaur1 https://folio-org.atlassian.net/browse/SIP2-150 |
INN-Reach | Redesigned ongoing record contribution to be aligned with the initial contributed outbox pattern design. |
|
|
| https://folio-org.atlassian.net/browse/UXPROD-4860 @Tim Auger |
FOLIO DCB/OpenRS | Modify the logic for creating a virtual service point (for pickup locations) and link up the default calendar. Also, modify default values of the calendar |
| Coordinate the DCB development that populates the creation of the SPs. Coordinate roll-out into production. |
|
https://folio-org.atlassian.net/browse/MODDCB-119 @Tim Auger |
Requests, Staff slips |
|
|
|
| @Anne Ekblad |
Automated patron blocks | Before Ramsons release, running automated patron block synchronization of any scope (“user” or “full”) would result in losing accumulated patron block data related to lost items for affected patrons. This may have affected libraries that use automated patron blocks with condition “Maximum number of lost items”. In order to rebuild lost data and recalculate patron blocks in these libraries it is recommended to run full patron block synchronization: POST /automated-patron-blocks/synchronization/job
{
"scope": "full"
}In case if potential data loss is limited to specific patron(s), a user-level sync can be executed instead: POST /automated-patron-blocks/synchronization/job
{
"scope": "user",
"userId": "USER_ID_HERE"
}Both calls will return an ID of the sync-job which can then be used to monitor job’s progress: GET /automated-patron-blocks/synchronization/job/JOB_ID_HERE |
|
| Institutions may run into a known bug when trying to run a full sync. | @Stephanie Buck |
MARC validation | Record specifications were implemented to be used for MARC validation |
| In case “9“ subfield specifications are missing - trigger | In case mod-entities-links starts before mod-record-specifications - “9“ subfield rules related to instance-authority linking might be missing from bib record specification. Issue is fixed for Sunflower | @Khalilah Gambrell @Viacheslav Kolesnyk |
MARC Validation (Ramsons CSP #7) | Apply script to resolve 856 subfield validation rule error. If your institution has updated MARC bib validation rules prior to Ramsons version 1.0.5. |
| Apply this script if your institution has updated MARC bib validation rules prior to Ramsons version 1.0.5. If your institution upgraded to Ramsons with a version prior to 1.0.5 AND you have not modified any rules then run POST /specification-storage/specifications/{specificationId}/sync endpoint to get most recent MARC bib/authority validation rules which includes this change.
|
| @Khalilah Gambrell @Pavlo Smahin |
Data Import, Field mapping profiles for Orders | Updated migration script to remove redundant entry for the "donor information" field that may have been added due to repeated migration script execution during the upgrade from Quesnelia (Quesnelia CSP#4 or higher) to Ramson, which causes profile to be corrupted during editing. | If ‘Order’ mapping profiles are edited after repeated migration script execution during the upgrade from Quesnelia (Quesnelia CSP#4 or higher) to Ramson, then these profiles can become corrupted. | If ‘Order’ mapping profiles have not been edited before upgrade to Ramsons CSP 2, then there should be no issue. If ‘Order’ mapping profiles have been edited after migration to Ramsons, but before Ramsons CSP 2, then they may be corrupted and show mappings assigned to incorrect fields. In this scenario, affected profiles will need to be recreated (not duplicated) and then linked to necessary Job profiles. |
| @Ryan Taylor |
Grails based modules (mod-agreements, mod-licenses, mod-service-interaction, mod-serials-management) | Issues can occur with federated locks during module upgrade/activation | These issues are resolved in Ramsons CSP 9, so this advice only applies when running module versions before:
| For all modules, the advice given at https://github.com/folio-org/mod-agreements?tab=readme-ov-file#locks-and-failure-to-upgrade applies for Ramsons releases before CSP#9. From Ramsons CSP#9 onwards we no longer recommend clearing federated lock table manually. Following CSP#9 the system is designed to be self-healing and manual actions to clear the federated locks could cause issues |
| @Owen Stephens @Ethan Freestone
|
Data Export | “Invalid CQL syntax” error is displayed when data export job is triggered cql after the updated from Quesnelia to Ramsons when mod-search runs on OpenSearch v2.x
| Two addtional permissions on the OpenSearch user/role used by mod-search with tenants on OS v2.x are needed: OpenSearch v1.x is not affected by this. |
|
|
|
