/
Sunflower (R1 2025) Critical Service Patch #8 - Modules release deadline: June 15 | GA date: June 22

Sunflower (R1 2025) Critical Service Patch #8 - Modules release deadline: June 15 | GA date: June 22

MOD RELEASE DEADLINE JUNE 15

RELEASED AT JUNE 22 Dashboard

Notes on Functionality by Area

Issues Impacting Functionality - Acquisitions

The following edge case is addressed with this CSP: When no encumbrance rollover options are selected, encumbrances are correctly created with $0.00 amount in "Released" status for the new FY, and the PO line links to the current FY encumbrance.

In the scenario when "Ongoing encumbrances” is active but "One-time encumbrances” is not, the PO line for a one-time order incorrectly references the previous FY encumbrance, and a new encumbrance is created with $0.00 amount and in "Unreleased" status. For more details: MODFISTO-559

 

Issues Impacting Functionality - ERM (Agreements, eholdings, Licenses, eUsage)

 

File uploads to S3 in Agreements and Licenses now supported using implicit role authorisation: For details see https://folio-org.atlassian.net/browse/UXPROD-5676 and see wiki documentation https://folio-org.atlassian.net/wiki/x/75JW for configuration information

Security fixes: No functional impact

 

Issues Impacting Functionality - Platform

Addressed issue with inaccurate error message displayed when entering invalid login credentials. For more details: MODLOGINKC-71

No other issues impact functionality. The other issues pertain to hardening platform security through dependency upgrades, fixing login-related regressions caused by those upgrades, and making infrastructure configuration more flexible for operators

 

Issues Impacting Functionality - User Management

No Functional impact.

Issues Impacting Functionality - Circulation & Fulfillment

Printing Pick Slips Fix

  • Rollback — A recent change that inadvertently stopped pick slips from printing was rolled back, restoring normal printing behavior for library staff. For more details CIRC-2621

Bursar export Fix

  • After saving the transfer criteria with distinct header and footer elements, if you navigate away from that settings page, then go back, the header elements have been copied to the footer, overwriting the elements that had previously been added to the footer. For more details UIPBEX-73

INN-Reach Fixes (interlibrary lending)

  • RECALL transaction status not being properly accounted for in the INN-Reach circulation flow.

    • Patron cancellation notices weren't being sent — When a lending library cancelled an INN-Reach Patron Hold request, FOLIO was cleaning up the virtual records too early, before the cancellation notice had a chance to go out to the patron. The fix reorders the process so the notice is sent first, and then the clean-up happens. This was reported by Grand Valley State University and Michigan State. https://folio-org.atlassian.net/browse/MODINREACH-574

    • Final check-in wasn't recognized after a recall — When an INN-Reach Item Hold transaction was in "RECALL" status and the item was checked back in, the system didn't recognize it as a final check-in. It just left the transaction stuck in RECALL. The fix ensures that checking in an item at any status after ITEM_SHIPPED (including RECALL) is properly handled as a final check-in. https://folio-org.atlassian.net/browse/MODINREACH-575

    • In-transit messages ignored during recall — Similar to the above, when a transaction was in RECALL status, the system was ignoring incoming IN_TRANSIT messages from the central server. The fix allows the transaction to correctly transition to IN_TRANSIT regardless of whether it's in RECALL status. This was reported by GVSU. https://folio-org.atlassian.net/browse/MODINREACH-576

  • Addressed "retry storm" during central server slowdowns — When the INN-Reach central server was slow or under maintenance, circulation events processed through Kafka would time out and trigger massive cascading retries. A single failing record could cause the entire batch to be replayed. Resolved the issue that caused excessive retries and latency issues. For more details MODINREACH-572

  • Timeouts permanently killed contribution items instead of retrying them — When the module checked whether the central server was valid during an ongoing contribution, a timeout would cause the outbox record to be marked as FAILED — permanently. The fix ensures that timeout errors are treated as temporary, marking the record as RETRY instead so the contribution can succeed once the central server recovers. For more details MODINREACH-581

OpenRS (consortial borrowing) Fixes

  • Lender transactions got stuck when the same item had other holds — When a lending library's DCB transaction expired (e.g., a patron didn't pick up the item in time) and there were other hold requests for the same item at the home library, the transaction would stay stuck in EXPIRED status indefinitely. It would only close once all holds were fulfilled and the item became "Available" again. The fix ensures the transaction properly closes based on the item's check-in activity, following standard FOLIO circulation logic — regardless of whether other patrons have holds queued up. For more details MODDCB-267

  • Expired transactions blocked new ones for the same item — In a multi-library borrowing flow, if a Borrower or Pickup transaction expired but didn't fully close, the system refuses to create a new transaction for the same item. The fix allows a new transaction to be created even when an expired one still exists, so libraries aren't stuck waiting for stale transactions to clear out before re-requesting an item. For more details MODDCB-271

  • Shadow location couldn't be updated on a re-request — When a borrowing or pickup DCB transaction was created using a "shadow" location (a virtual stand-in for a remote library's location), updating the transaction to point to a different shadow location didn't actually change the item's effective location. This meant re-requests that needed to redirect an item to a different lending library's shadow location would silently fail. The fix ensures the effective location is properly updated across all role types (Borrower, Borrowing-pickup, Pickup) and all location-change combinations (shadow-to-shadow, shadow-to-default, default-to-shadow). For more details MODDCB-270

  • Lender transactions got stuck when the same item had other holds — When a DCB lending transaction expired (e.g., a patron didn't pick up the item within the hold shelf time limit), the transaction was supposed to close once the item was checked back in at its home library. Instead, if other patrons had hold requests queued up for that same item, the transaction would stay stuck in EXPIRED status indefinitely. It would only finally close once every hold in the queue was fulfilled and the item's status returned to "Available" — which could take a very long time or never happen at all. For more details MODDCB-267

    • The fix ensures the transaction properly closes based on the item's check-in activity, following standard FOLIO circulation logic. Specifically:

      • If the next request in the queue is at the same pickup service point, the item stays "Awaiting pickup" and the next patron is served — but the expired DCB transaction still closes.

      • If the next request is at a different pickup service point, the item transitions to "In transit" — and the expired DCB transaction still closes.

    • Either way, the DCB transaction no longer waits for the entire request queue to drain before closing.

 

Issues Impacting Functionality - Metadata Management

Inventory app Fixes

  • Items did not render under Holdings accordion in Inventory instance detail view.

  • Moving holdings from one instance to another

    • Item barcode searching returned the wrong result. For more details MODINVSTOR-1554

    • When a library staff member moves a holdings record from one Instance (bibliographic record) to another in Inventory, the system was only marking the destination Instance as updated — it wasn't marking the source Instance (the one the holdings moved away from) as changed. This matters because the discovery layer (the public-facing catalog) uses an internal timestamp called complete_updated_date to figure out which records have changed since the last harvest. Since the source Instance wasn't getting that timestamp refreshed, the discovery layer never picked up that it had changed, so patrons could still see stale data. For more details MODINVSTOR-1542

  • ECS Only: Instance details pane froze when at least 30 holdings records exist per each tenant.

  • Non-ECS Only: Create/Edit item record took too long to save. For more details MODINVSTOR-1571

MARC validation rules

Issues Impacting Functionality - Data import

  • After a MARC file import completes successfully, clicking the file name in the import log fails to load log details. The pane shows "The list contains no items.” For more details MODSOURMAN-1429

Issues Impacting Functionality - Data Export & OAI-PMH

OAI-PMH Fix

  • Improved harvesting of delete records. When harvesting deleted MARC records there were too many checks for the delete status. The fix simplies what value to check and thus decreases the chances of a failed harvest.

Issues Impacting Functionality - Bulk-edit

When a user uses Find and Remove or Find and Replace functions in such way that the entire value of the field is removed then the field itself should be removed as well. For more details MODBULKOPS-672

Issues Impacting Functionality - Lists & Reporting

No Functional Impact.

APPROVAL LOG

Tickets List

Modules list

Release tag

https://github.com/folio-org/platform-lsp/releases/tag/R1-2025-csp-8

Configuration

CSP

Functional Area

Change or Additions

Considerations

Action timing,
Action required

Comments

Contact person,
Related JIRAs

CSP

Functional Area

Change or Additions

Considerations

Action timing,
Action required

Comments

Contact person,
Related JIRAs

CSP8

OAI-PMH

Based on the introduction of the “Set for deletion” functionality for inventory instance records, OAI-PMH now uses a unified source of truth for deleted FOLIO and MARC instances. Records are considered deleted when the Inventory instance flag “Set for deletion” is set to true.

A migration script has been added to identify and update instances where MARC records have LDR 05 set to “d”, but the associated Inventory instance “Set for deletion” flag is set to false. Most of these records were created before the “Set for deletion” flag was introduced.

The migration script updates “Set for deletion”, “Staff suppress” and “Suppress from discovery” flags for instances that have LDR set to “d” in the underlying SRS records. The script also logs history records for all changes.

 

All records updated with the migration script will be included in the incremental harvest that runs after the migration script have been completed so that downstream systems receive accurate deletion information.

Run this migration if your FOLIO system contains historical MARC deletions (from SRS) prior to “Set for deletion”, and you want these reflected in Inventory and discoverable via OAI-PMH.

If your system was initialized after the transition to Inventory-based deletion tracking, or you have no legacy SRS deletions, or you don't care about deleted SRS records produced prior “Set for deletion” functionality, migration may not be necessary

Link to the migration script: https://github.com/folio-org/mod-inventory/tree/master/scripts

@Mikita Siadykh