- Inventory items now have a restricted set of valid statuses. Environments which are using their own statuses will need to change their records accordingly. The statuses are as follows (the capitalisation is important): Available; Awaiting pickup; Awaiting delivery; Checked out; In process; In transit; Missing; On order; Paged; Declared lost; Order closed and Claimed returned.
- Overdue fine policies must be set up and circulation rules have to refer to policies that exist. If you do not charge overdue fines, you need to create one overdue fine policy that is for an overdue fine of 0 and use that overdue fine policy for every circulation rule.
- Lost item fine policies must be set up and circulation rules have to refer to policies that exist. If you do not charge lost item fees, you need to create one lost item fee policy that is for a lost item fee of blank and use that lost item fee policy for every circulation rule. Here is an example of a default Lost Item Fee Policy to use if you do not charge lost item fees. The one required setting you will need to enter is the For lost items not charged a fee/fine, close the loan after interval. This setting is needed to insure that the loan is eventually closed.
- Upon deployment make sure that automatic fee/fine types were added to the
mod-feesfinesdatabase. Otherwise overdue fine creation functionality will not work for Q1 2020 release and lost item processing will not work for Q2 2020 release. 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."
- All Service Points must be associated with a Fee/Fine Owner at Settings>Users>Fee/Fine: Owners for overdue fines to work properly. If an overdue fine is calculated for an item with an Effective Location whose Primary Service Point is not associated to a Fee/Fine Owner, the overdue fine 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-calendar: History/audit tables (table names starting with
audit_) are truncated (all data deleted) on upgrade. The format of the audit tables has been changed in RMB 25.0.0, there is no conversion because RMB versions before 25 were outdated and unsupported in Edelweiss.
- PubSub is being used and required in Fameflower. PubSub module allows use of the event-driven approach in cross-module interactions. This module works on top of Kafka/Zookeeper to deliver messages and create a queue of events. For supporting messaging between modules and correct PubSub mechanism work, it needs to have a Kafka/Zookeeper stack for FOLIO environments. It's important to have the right order on environments setup. First of all, start Kafka, then mod-pub-sub and after it, all other modules with dependencies on PubSub modules. For more information on installation or verifying that Kafka and PubSub are working together properly, consult the PubSub readme documentation or contact Oleksii Kuzminov Taras Spashchenko.
- Organizations codes must now be unique. This will prevent the migration of your organization records from Edelweiss to Fameflower if the Code they are using is used by another organization that was migrated first. There is a fix, but it was decided that this can wait until the Q2 release so there will be no Hotfix. A workaround would be making sure you have no duplicate code before the migration begins. JIRA issue
Jira server FOLIO Issue Tracker columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 6ccf3fe4-3301-368a-983e-20c466b11a49 key MODORGSTOR-68
- User barcodes must be unique. This includes barcodes which have been set to an empty string. To workaround make sure you have no duplicate barcode before the migration begins.
Jira server FOLIO Issue Tracker serverId 6ccf3fe4-3301-368a-983e-20c466b11a49 key MODUSERS-192
- mod-data-export is a new module which can be used to export bibliographic data in MARC binary format. For Q1 the only supported storage for file export will AWS S3. For configuration steps please see (https://github.com/folio-org/mod-data-export/blob/master/README.md)(For questions contact Kruthi Vuppala / Magda Zacharska )
(Note: There will be platform agnostic implementations in future releases)
- raml module builder (RMB) based back-end modules should use RMB version 29.3.* or 29.4.*. The platform core team will provide hot-fixes only for these versions during the period of time where Fameflower is the latest FOLIO release. The module spreadsheet indicates each module's RMB version.
- raml module builder (RMB) based back-end modules should not be installed or updated in parallel but one by one in sequence. Otherwise some might fail with "tuple concurrently updated" (RMB-598).