Summary: | RestrictPatronsWithFailedNotices should not trigger for DUPLICATE_MESSAGE failures | ||
---|---|---|---|
Product: | Koha | Reporter: | Kyle M Hall (khall) <kyle> |
Component: | Notices | Assignee: | Kyle M Hall (khall) <kyle> |
Status: | Needs Signoff --- | QA Contact: | Testopia <testopia> |
Severity: | normal | ||
Priority: | P5 - low | CC: | lin-wei.li |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
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: | ||
Bug Depends on: | 23295 | ||
Bug Blocks: | |||
Attachments: |
Bug 39749: RestrictPatronsWithFailedNotices should not trigger for DUPLICATE_MESSAGE failures
Preconfigured KTD Database for testing |
Description
Kyle M Hall (khall)
2025-04-25 14:26:18 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! # 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. 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 Created attachment 182597 [details]
Preconfigured KTD Database for testing
I've deleted all biblio records to shrink the file size.
|