R2 2021 (Juniper) Release Notes

R2 2021 (Juniper) Release Notes





















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

Action required

Action timing

Contact person

Comments

Related JIRA issues

Functional Area

Change or Addition

Considerations

Action required

Action timing

Contact person

Comments

Related JIRA issues

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

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

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

User name of person that can provide additional detail

Name of user leaving comment: comment on what you encountered or ask a question @mention Contact person

Include issue link for bug fix, story or feature that applies

mod-source-record-manager

Corrected the default MARC-to-Instance mapping for the 647 field

Individual tenants often adjust the default MARC-to-Instance map to include or exclude particular MARC fields

Review each  tenant's production MARC-to-Instance default mappings, and adjust the 647 field: https://github.com/folio-org/mod-source-record-manager/blob/master/mod-source-record-manager-server/src/main/resources/rules/marc_bib_rules.json#L5648

After upgrade

@Ann-Marie Breaux (Deactivated)



MODSOURMAN-448

mod-source-record-manager

Increased the default limit for the number of reference values that can be looked up from 500 to 1000, and added a way to change the configuration in case a higher limit is needed. 

If a tenant has more than 500 values for particular settings (e.g. locations, funds), Data Import previously could only retrieve the first 500. That caused incorrect location assignments for libraries with 500+ locations. The default has been changed to 1,000, and a new variable created to allow for higher settings.



This limit is for data from this class (see constants from this class): https://github.com/folio-org/mod-source-record-manager/blob/86835f64a1f5e29e3350899b04807941327d54ec/mod-source-record-manager-server/src/main/java/org/folio/services/mappers/processor/MappingParametersProvider.java#L91 

As of v 3.1.3 there is a new property which defines the limit for retrieving data to fill mapping parameters for the data-import mechanism: "srm.mapping.parameters.settings.limit:1000" (default=1000).

This setting controls the number of items that will be retrieved from specific endpoints for Data-Import matching and field mappings. If a higher limit is needed by a particular tenant, the setting can be adjusted.

See more info in the README.md-file in mod-source-record-manager: mod-source-record-manager/README.md at master · folio-org/mod-source-record-manager (github.com)"

After upgrade

@Ann-Marie Breaux (Deactivated)

@Kateryna Senchenko



MODSOURMAN-535

MODDICORE-165

mod-source-record-storage

In Iris, an end point was added to allow searching MARC records. If the script to add records to the search was not run on your tenant for Iris, then it will be need to run for Juniper if you wish to use the search.

The end point will only return results from MARC records added after installation of Iris. A script to retroactively process pre-existing records has  been developed, see MODSOURCE-276: Add existing records to the SRS Query API table

To add records  that existed prior to  upgrade to the query search  see MODSOURCE-276: Add existing records to the SRS Query API table Script: https://github.com/folio-org/mod-source-record-storage/blob/master/mod-source-record-storage-server/src/main/resources/migration_scripts/fill_marc_indexers.sql

Before or after upgrade, if never run before or if you have records that need to be added to the query search.

@Jenn Colt @Igor Gorchakov @Khalilah Gambrell





mod-service-interaction





To ensure that the widget definitions made available by mod-agreements and mod-licenses are available, mod-service-interaction should be initialised with the tenantParameter `loadSample%3Dtrue` specified.

On initialising the module for the first time

@Ethan Freestone



https://folio-org.atlassian.net/browse/ERM-1778

mod-feesfines

Upon deployment make sure that automatic fee/fine types were added to the mod-feesfines database.  Otherwise automatic fine creation functionality will not work.

To check, make a call to /feefines?query=automatic==true.  The response should contain 4 entries: "Overdue fine", "Lost item fee", Lost item processing fee" and "Replacement processing fee."

To check, make a GET call to /feefines?query=automatic==true.  The response should contain 4 entries: "Overdue fine", "Lost item fee", Lost item processing fee" and "Replacement processing fee." If response is empty, execute the following script manually and check again:

https://github.com/folio-org/mod-feesfines/blob/v16.1.1/src/main/resources/templates/db_scripts/populate-feefines.sql









mod-circulation

All Service Points must be associated with a Fee/Fine Owner at Settings>Users>Fee/Fine: Owners for overdue fines and lost item fees to work properly.  If an overdue fine/lost item fee is calculated for an item with a Location whose Primary Service Point is not associated to a Fee/Fine Owner, the overdue fine/lost item fee will NOT be charged to the patron.

In the future we will have a Default Fee/fine Owner to be charged.  (See UXPROD-2278 for details.)











mod-circulation

For Iris, the scheduled aged to lost endpoints were removed from FOLIO to allow for individual institutions to schedule them. In Juniper, add'l OKAPI timer functionality was introduced that allowed those endpoints to be brought back into FOLIO.











https://folio-org.atlassian.net/browse/CIRC-1144

mod-search

Need to add a new environment variable

Module can read Kafka messages from other envs

New environment variables should be added for mod-search.

ENV - The logical name of the deployment, must be unique across all environments using the same shared Kafka/Elasticsearch clusters. See details.

KAFKA_EVENTS_CONSUMER_PATTERN - regexp pattern for Kafka consumers to subscribe. 

Value for this property should be ({ENV}\.)(.*\.)inventory\.(instance|holdings-record|item)

Important! {ENV} should be replaced with the same value as the value for the ENV property. 

Example:

ENV: bugfest

KAFKA_EVENTS_CONSUMER_PATTERN: (bugfest\.)(.*\.)inventory\.(instance|holdings-record|item)



@Oleksii Kuzminov @Pavel Filippov





mod-source-record-storage

“2020-09-09--15-00-fill-instance-hrid” migration script will no longer fail the upgrade in case MARC records with multiple "001" fields present in the DB.

MARC records with multiple "001" fields might fail to update via data-import process or by quick-marc edit.

Run check_001_field_duplicates.sql script to find MARC records with multiple "001" fields, review and correct the data.

Before upgrade (or on a periodic basis in case data are imported to SRS bypassing data-import)

@Ann-Marie Breaux (Deactivated)

@Kateryna Senchenko 



https://folio-org.atlassian.net/browse/MODSOURCE-359

https://folio-org.atlassian.net/browse/MODSOURCE-357

Inventory

Item barcode is unique
We removed the item barcode changes from Juniper. They will ship with Kiwi.

Duplicate item barcodes fail the upgrade.
Upgrade error response mentions index name item_barcode_idx_unique.
mod-inventory-storage log mentions actual duplicate barcode.

Before upgrade:
Change all duplicate item barcodes.
Find them with this SQL:
SET search_path TO diku_mod_inventory_storage;
SELECT lower(jsonb->>'barcode')
FROM item
GROUP BY 1
HAVING count(*) > 1;

Use Inventory Item Barcode search to edit the duplicate barcode.

Before upgrade

@Julian Ladisch



https://folio-org.atlassian.net/browse/MODINVSTOR-523

Inventory

Manual publicationPeriod migration

When migrating from Iris to Juniper HotFix#3 or later there is no automatic population of publicationPeriod. When migrating to Juniper GA, HotFix#1 or HotFix#2 publicationPeriod is automatically populated during migration.

Manually populate publicationPeriod. Details: https://github.com/folio-org/mod-inventory-storage/blob/master/src/main/resources/templates/db_scripts/populatePublicationPeriod.sql

Before or after upgrade

@Julian Ladisch



(MODINVSTOR-774, MODINVSTOR-806, MODINVSTOR-811, MODINVSTOR-812)

Dashboard

Populate widget definitions



To ensure that dashboard has all the available dashboard widget definitions:

  • Assign a user the permission `servint.admin.action`

  • With that user, issue a GET to Okapi endpoint /servint/admin/triggerTypeImport - this will import all available widget definitions from modules that supply them

After upgrade 

@Owen Stephens



https://folio-org.atlassian.net/browse/ERM-1778

Stripes

Nodejs LTS version changed from 14 to 16

yarn install fails when using Node 16: "gyp ERR! not ok"

Pin the version of n to 14

Before upgrade





https://folio-org.atlassian.net/browse/FOLIO-3323

Loan Anonymization

Changes to ensure that loan anonymization processes all open loans. 

Prior to Juniper bugfix the anonymization process only fetched 5,000 loans at a time, so if you had more than 5,000 loans that needed to be processed for anonymizing, it wouldn't get entirely through the process, introducing inconsistencies. 

A new approach was implemented:

  • increase number of checked loans to 50,000

  • increase interval between runs to 1 hour

  • increase guideline mem requirements for module

If the new approach is acceptable, no changes are needed.

If you want to increase or decrease the number of checked loans at a time, you can do it through an environment variable

If you want to increase or decrease the interval between runs, you can override that in Okapi

Note that the anonymization process needs to finish one run before beginning the next run in order to minimize inconsistent behavior. That should be factored into your considerations if you want to change the number of loans and interval. There is significant discussion of the ramifications in the comments of https://folio-org.atlassian.net/browse/CIRC-1178

After upgrade



SME questions about this are best directed to the #resource-access channel on Slack

https://folio-org.atlassian.net/browse/CIRC-1178

mod-data-import

Set the chunk size value

mod-source-record-storage might crash with OOM during the Update import of 5,000 records if chunk size parameter is left with default value of 50 records

file.processing.buffer.chunk.size system property should be set to 5



@Kateryna Senchenko @Aliaksandr Fedasiuk 

@Kateryna Senchenko 



mod-source-record-manager and mod-source-record-storage

Set max request size

Import of large EDIFACT file can fail if size of the payload exceeds the default value of 1048576 bytes

MAX_REQUEST_SIZE should be set to 4000000 (or higher) for mod-source-record-manager and mod-source-record-storage.

Alternatively, the file.processing.buffer.chunk.size can be set to 10 (or smaller) for mod-data-import



@Kateryna Senchenko @Aliaksandr Fedasiuk 

@Kateryna Senchenko 



mod-source-record-manager



Applicable only for libraries that are customising their default mapping rules for MARC records.

mapping_rules db table may contain default (not customised) versions of mapping rules for MARC records alongside the customised mapping rules

To ensure customised default mapping rules for MARC records are used consistently do the following:

  1. Send GET request to  /mapping-rules to retrieve the mapping rules

  2. Send PUT request to /mapping-rules and put in the body the result of step 1

After upgrade

@Kateryna Senchenko 






New Apps

Dashboard

The dashboard is designed to enable a personalised view of key information from across Folio apps at a glance. In its first release (included in the Juniper flower release) the dashboard includes the ability to display information from the Agreements and Licenses applications. Documentation on using the Dashboard is available at Introduction to Dashboard, and information for developers wishing to take advantage of dashboard functionality for their own apps is available at Dashboard Documentation. Users will need the new "Dashboard: Manage dashboard" permission assigning to be able to see and use the dashboard application.

CaiaSoft remote storage integration

Remote storage integration for CaiaSoft. Accessed through Settings > Remote storage and Settings > Remote storage and Settings > Tenant > Location. CaiaSoft accession tables are populated with location data and are only available once a configuration is created and saved.

Permissions Updates

App

New Permissions

Deprecated Permissions

Product Owner

App

New Permissions

Deprecated Permissions

Product Owner

Dashboard

Dashboard: Manage dashboard (permissionName: ui-dashboard.dashboards.manage). A user with this permission can create a dashboard and add, edit, remove and re-order widgets on their dashboard

n/a

Owen Stephens

Remote storage integration

Remote storage: View A user with this permission can view remote storage configurations

Remote storage: Create, edit, delete A user with this permission can create, edit and delete remote storage configurations.

Remote storage: All

Stephanie Buck

Known Issues

App

Known issue

Workaround

JIRA issue

Product Owner

App

Known issue

Workaround

JIRA issue

Product Owner

Data Import

EDIFACT invoice files must have a file extension of .inv or .edi (case does not matter)

Rename the EDIFACT file's extension to .inv or .edi

https://folio-org.atlassian.net/browse/MODDATAIMP-472

@Ann-Marie Breaux (Deactivated)

Data Import

If a default EDIFACT field mapping profile is copied, and then the Vendor Reference Number field mapping is completely removed, that results in a bug. 

1) If removing the field mapping for Vendor Reference Number, create a new field mapping profile instead of duplicating an existing one. 2) If duplicating an existing field mapping profile, instead of entirely removing the Vendor Reference number field, leave some value in it, even if the field will not be used to match to the relevant POL.

UIDATIMP-987

@Ann-Marie Breaux (Deactivated)

Data Import

If a tenant has more than 10 acquisitions units, only the first 10 will display in the Invoice field mapping profile dropdown list.

None (will be corrected in Kiwi)

UIDATIMP-1008

@Ann-Marie Breaux (Deactivated)

Data Import

Default - Create SRS MARC Authority job profile displays in Data Import Settings, but cannot be used yet

Load directly with the API to store MARC Authority records in SRS. Note that there is no UI access to these records yet. That will be delivered in future functionality



@Khalilah Gambrell

Settings > Circulation > Other Settings

Juniper added the option to configure check out to allow for looking up patrons by custom ID fields. The upgrade to Juniper to add that option reset settings and unchecked boxes that had been checked in previous releases.

After upgrade, re-check the boxes for the desired ids in 'Patron ids for checkout scanning'

https://folio-org.atlassian.net/browse/MODCONF-96

@(OLD ACCOUNT) Erin Nettifee

Patron blocks

Automated patron blocks sometimes do not clear when 

  1. item renewed for patron with a large volume of loans

  2. aged to lost item returned 

This can be caused by some of the event messages being lost on the way from mod-feesfines to mod-patron-blocks through pub-sub/Kafka, so the data is out of sync. You can re-sync automated patron blocks data for a single patron like this:

POST /automated-patron-blocks/synchronization/job

body:

{ "scope": "user", "userId": "{USER_ID}" }

or you can do a full re-sync for all patrons (this can take a lot of time depending on the amount of loans, fees/fines and other data):

POST /automated-patron-blocks/synchronization/job

body:

{ "scope": "full" }

These calls return a sync job object with an ID, you can use this ID to monitor its status, number of processed objects, errors etc.:

GET /automated-patron-blocks/synchronization/job/{SYNC_JOB_ID}

MODPATBLK-109 and 

MODPATBLK-112

@Holly Mistlebauer 
@Stephanie Buck 

Requests/Patron Services (mod-patron/edge-patron)

If the user performing the action (or the service user in-use with mod-patron/edge-patron) does not have permissions to read fixed due date schedules, recalls of loans with fixed due dates will fail.

The workaround is to ensure that the user account has the following permissions (invisible) assigned, either directly or via another permission set:

  • Circulation storage - get fixed due date collection

  • Circulation storage - get individual fixed due date

https://folio-org.atlassian.net/browse/CIRC-1449

@Brooks Travis 

Staff slips

Staff slips generate an extra blank page, if your staff slip is only one page long.

Sorry, no work around... but it has been fixed and released in Kiwi.

https://folio-org.atlassian.net/browse/UICIRC-683

@julie.bickle 

General

Acquisitions:

key summary type priority status resolution reporter Release Potential Workaround
Loading...
Refresh

Notes on functionality

Permissions

Deployment Considerations
  • If you want to benefit from permission migration you need OKAPI v4.6.0 or greater (v4.7.2 or greater is highly recommended) and mod-permissions v5.13.0.

  • Contrary to earlier communications, it is NOT required to upgrade mod-permissions first or last.  It is also NOT required that you upgrade to the latest Honeysuckle Hot Fix release prior to upgrading to Iris.

Please contact the @Craig McNally, @Adam Dickmeiss, or @Jakub Skoczen with questions.

Data Import

Inventory

  • Juniper GA, HotFix#1 and HotFix#2 ship with a Java-based migration process for instance publicationPeriod property. This process has been disabled for HotFix#3 and later. The migration process has following impact:

    • Module initialization takes significant time for migration version (the process is triggered only once), depending on the number of instances to populate it may take 5 hours or more than 30 hours. It is recommended to run this process at non working hours, because mod-inventory-storage is a critical part of FOLIO, most subsystems will be unresponsive.  (MODINVSTOR-774, MODINVSTOR-806, MODINVSTOR-811)

    • The migration process does not generates domain events for updates.

  • Known issue (MODINVSTOR-940) Missing migration script to populate Effective location for holdings without items