Bug 39019

Summary: Do not repeat content in CHECKOUT, CHECKIN, and HOLDDGST notices when digest tags are omitted
Product: Koha Reporter: Andrew Fuerste-Henry <andrew>
Component: NoticesAssignee: Bugs List <koha-bugs>
Status: NEW --- QA Contact: Testopia <testopia>
Severity: normal    
Priority: P5 - low CC: hebah, kebliss
Version: Main   
Hardware: All   
OS: All   
GIT URL: Change sponsored?: ---
Patch complexity: --- Documentation contact:
Documentation submission: Text to go in the release notes:
Version(s) released in:
Circulation function:

Description Andrew Fuerste-Henry 2025-02-03 14:58:04 UTC
The CHECKOUT, CHECKIN, and HOLDDGST notices assume some content will appear in the notice once, while other content will be generated per item. The content to be repeated gets wrapped in a set of dashed lines that I called "digest tags" in the bug title. Like:

Hey Patron,
These books got checked out:
----
[% biblio.title %]
----


While a full list of titles works well in an email, it can get prohibitively long in an SMS, so some libraries prefer a single static line for their SMS notice. However, if one fully omits those digest tags Koha will repeat the entire notice per item. 

If no digest tags are included in the template, Koha should not repeat any of the content on subsequent items.

To recreate:
1: Edit the CHECKOUT notice to read:

Test
----
----

2: check two items out to a patron set to receive CHECKOUT notices
3: confirm their notice says just "Test"
4: Edit the checkout notice to read:

Test

5: check two items out to a different patrons set to receive CHECKOUT notices
6: confirm their notice says "TestTest"
Comment 1 Katrin Fischer 2025-02-03 16:44:43 UTC
The problem is that the notice is not build "as a whole" but "in little bits". Meaning that which each transaction Koha opens the notice already generated, looks for the marker to determine where the next entry has to go and then adds it there. I don't think it will work without some type of "repetition" marker. Maybe these type of notices are not well suited for SMS.

Hm, but maybe it could just do nothing if they are missing?
Comment 2 Andrew Fuerste-Henry 2025-02-05 19:08:14 UTC
(In reply to Katrin Fischer from comment #1)
> Hm, but maybe it could just do nothing if they are missing?

That'd be my preference, if possible.