R2 2021 (Juniper) Release Notes

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

MODSOURMAN-535

MODDICORE-165

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.

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

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)

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.

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

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

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

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

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

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.

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

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