Bug 39749 - RestrictPatronsWithFailedNotices should not trigger for DUPLICATE_MESSAGE failures
Summary: RestrictPatronsWithFailedNotices should not trigger for DUPLICATE_MESSAGE fai...
Status: Needs Signoff
Alias: None
Product: Koha
Classification: Unclassified
Component: Notices (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low normal
Assignee: Kyle M Hall (khall)
QA Contact: Testopia
URL:
Keywords:
Depends on: 23295
Blocks:
  Show dependency treegraph
 
Reported: 2025-04-25 14:26 UTC by Kyle M Hall (khall)
Modified: 2025-06-02 15:24 UTC (History)
1 user (show)

See Also:
GIT URL:
Change sponsored?: ---
Patch complexity: Trivial patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
Bug 39749: RestrictPatronsWithFailedNotices should not trigger for DUPLICATE_MESSAGE failures (1.95 KB, patch)
2025-04-25 14:29 UTC, Kyle M Hall (khall)
Details | Diff | Splinter Review
Preconfigured KTD Database for testing (789.51 KB, application/x-gzip)
2025-05-19 11:42 UTC, Kyle M Hall (khall)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle M Hall (khall) 2025-04-25 14:26:18 UTC
Koha is built to prevent sending duplicate notices. Notices with static language ( e.g. "You have one or more holds ready to pick up" ) will easily trigger this filter.

RestrictPatronsWithFailedNotices should ignore these notices because they do not indicate any problem with contacting the patron.
Comment 1 Kyle M Hall (khall) 2025-04-25 14:29:35 UTC
Created attachment 181530 [details] [review]
Bug 39749: RestrictPatronsWithFailedNotices should not trigger for DUPLICATE_MESSAGE failures

Koha is built to prevent sending duplicate notices. Notices with static language ( e.g. "You have one or more holds ready to pick up" ) will easily trigger this filter.

RestrictPatronsWithFailedNotices should ignore these notices because they do not indicate any problem with contacting the patron.

Test Plan:
1) Enable RestrictPatronsWithFailedNotices
2) Enqueue to identical notices for a patron
3) Run process message queue to send one and fail the other as a
   duplicate ( alternately, just modify them in the database )
4) Run restrict_patrons_with_failed_notices.pl
5) Note the restriction
6) Remove the restriction
7) Apply this patch
8) Run restrict_patrons_with_failed_notices.pl
9) Note that no restriction was created!
Comment 2 Lin Wei 2025-05-12 15:22:32 UTC
# Test Result

Could not reproduce issue.

# Test Execution

1. Set "RestrictPatronsWithFailedNotices" to "Apply."
2. Enqueued 2 identical notices to a patron:
  - Subject: KOHA - Notice
  - Body: You have one or more holds ready to pick up
3. Ran `./misc/cronjobs/process_message_queue.pl`.
4. Both notices were sent successfully.
5. Manually update the DB: UPDATE message_queue SET status='failed' WHERE message_id=2;
6. Ran `./misc/cronjobs/restrict_patrons_with_failed_notices.pl`.
7. Patron does not have any restrictions.
Comment 3 Kyle M Hall (khall) 2025-05-19 11:38:02 UTC
I am still able to reproduce the issue. I'm attaching a pre-configured KTD database where Henry Acevedo will be restricted. To test just load the backup into KTD and run ./misc/cronjobs/restrict_patrons_with_failed_notices.pl -v -c
Comment 4 Kyle M Hall (khall) 2025-05-19 11:42:04 UTC
Created attachment 182597 [details]
Preconfigured KTD Database for testing

I've deleted all biblio records to shrink the file size.