[Dmytro-Melnyshyn]

Description

400+ lines are tests.

Adds a new Text message format alongside the existing Email/Print options for patron notice templates. Key changes:

• New NOTICE_FORMATS constant (EMAIL / PRINT / TEXT_MESSAGE) replacing the old printOnly boolean + implicit-email model.
• Edit form: "Email or print" checkbox replaced by a Select for additionalProperties.noticeFormat, driving whether Subject/Body are enabled, whether the body is plain text, and whether image tokens are offered.
• parseInitialValues/handleBeforeSave in PatronNotices.js translate between the legacy printOnly flag and the new noticeFormat field, and set outputFormats accordingly.
• View section now shows a "Notice format" KeyValue instead of "Subject".

Related PRs

folio-org/stripes-template-editor#120
folio-org/stripes-core#1752

Issues

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

Screencasts

2026-07-31_14h07_25.mp4

Approach

Refs

Screenshots

Pre-Merge Checklist

Before merging this PR, please go through the following list and take appropriate actions.

• I've added appropriate record to the CHANGELOG.md
• Does this PR meet or exceed the expected quality standards?
  • Code coverage on new code is 80% or greater
  • Duplications on new code is 3% or less
  • There are no major code smells or security issues
• Does this introduce breaking changes?
  • If any API-related changes - okapi interfaces and permissions are reviewed/changed correspondingly
  • There are no breaking changes in this PR.

If there are breaking changes, please STOP and consider the following:

• What other modules will these changes impact?
• Do JIRAs exist to update the impacted modules?
  • If not, please create them
  • Do they contain the appropriate level of detail? Which endpoints/schemas changed, etc.
  • Do they have all they appropriate links to blocked/related issues?
• Are the JIRAs under active development?
  • If not, contact the project's PO and make sure they're aware of the urgency.
• Do PRs exist for these changes?
  • If so, have they been approved?

Ideally all of the PRs involved in breaking changes would be merged in the same day to avoid breaking the folio-testing environment. Communication is paramount if that is to be achieved, especially as the number of intermodule and inter-team dependencies increase.

While it's helpful for reviewers to help identify potential problems, ensuring that it's safe to merge is ultimately the responsibility of the PR assignee.

[github-actions]

Jest Unit Test Results

    1 files  ± 0    192 suites  +3   1m 12s ⏱️ +5s
2 056 tests +36  2 056 ✅ +36  0 💤 ±0  0 ❌ ±0 
2 103 runs  +36  2 103 ✅ +36  0 💤 ±0  0 ❌ ±0 

Results for commit 85e0d77. ± Comparison against base commit bed0059.

This pull request removes 11 and adds 47 tests. Note that renamed tests count towards both.

PatronNoticeDetail with default props should render "Email or print" label ‑ PatronNoticeDetail with default props should render "Email or print" label
PatronNoticeDetail with default props should render "email" Accordion ‑ PatronNoticeDetail with default props should render "email" Accordion
PatronNoticeEmailEditSection should render "Body" label ‑ PatronNoticeEmailEditSection should render "Body" label
PatronNoticeEmailEditSection should render "Subject" label ‑ PatronNoticeEmailEditSection should render "Subject" label
PatronNoticeEmailEditSection should render component ‑ PatronNoticeEmailEditSection should render component
PatronNoticeEmailEditSection should trigger Field component for notice subject with correct props ‑ PatronNoticeEmailEditSection should trigger Field component for notice subject with correct props
PatronNoticeEmailEditSection should trigger Field component for patron notices body with correct props ‑ PatronNoticeEmailEditSection should trigger Field component for patron notices body with correct props
PatronNoticeEmailSection should render "subject" KeyValue ‑ PatronNoticeEmailSection should render "subject" KeyValue
PatronNoticeEmailSection should render label of "subject" field ‑ PatronNoticeEmailSection should render label of "subject" field
PatronNoticeForm with default props should render "Email or print" label ‑ PatronNoticeForm with default props should render "Email or print" label
…

PatronNoticeDetail with default props should render "Patron notice content" Accordion ‑ PatronNoticeDetail with default props should render "Patron notice content" Accordion
PatronNoticeEmailEditSection when no notice format is selected should call getTokens with images enabled ‑ PatronNoticeEmailEditSection when no notice format is selected should call getTokens with images enabled
PatronNoticeEmailEditSection when no notice format is selected should render "Body" label ‑ PatronNoticeEmailEditSection when no notice format is selected should render "Body" label
PatronNoticeEmailEditSection when no notice format is selected should render "Subject" label ‑ PatronNoticeEmailEditSection when no notice format is selected should render "Subject" label
PatronNoticeEmailEditSection when no notice format is selected should render component ‑ PatronNoticeEmailEditSection when no notice format is selected should render component
PatronNoticeEmailEditSection when no notice format is selected should trigger Field component for patron notices body with correct props ‑ PatronNoticeEmailEditSection when no notice format is selected should trigger Field component for patron notices body with correct props
PatronNoticeEmailEditSection when no notice format is selected should trigger TextField component for notice subject with correct props ‑ PatronNoticeEmailEditSection when no notice format is selected should trigger TextField component for notice subject with correct props
PatronNoticeEmailEditSection when notice format is email should call getTokens with images enabled ‑ PatronNoticeEmailEditSection when notice format is email should call getTokens with images enabled
PatronNoticeEmailEditSection when notice format is email should trigger Field component for patron notices body with plainText disabled ‑ PatronNoticeEmailEditSection when notice format is email should trigger Field component for patron notices body with plainText disabled
PatronNoticeEmailEditSection when notice format is text message should call getTokens with images disabled ‑ PatronNoticeEmailEditSection when notice format is text message should call getTokens with images disabled
…

♻️ This comment has been updated with latest results.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
97.9% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud