Bug 14964 - Email notices will be queued for patrons with no email address and generate warnings
Summary: Email notices will be queued for patrons with no email address and generate w...
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: Notices (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Kyle M Hall (khall)
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-06 12:30 UTC by Kyle M Hall (khall)
Modified: 2026-02-03 11:32 UTC (History)
5 users (show)

See Also:
GIT URL:
Initiative type: ---
Sponsorship status: ---
Comma delimited list of Sponsors:
Crowdfunding goal: 0
Patch complexity: Small patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
Bug 14964 - Email notices will be queued for patrons with no email address (2.09 KB, patch)
2015-10-06 12:41 UTC, Kyle M Hall (khall)
Details | Diff | Splinter Review
Bug 14964 - Email notices will be queued for patrons with no email address (2.10 KB, patch)
2015-10-06 12:42 UTC, Kyle M Hall (khall)
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle M Hall (khall) 2015-10-06 12:30:14 UTC
If a patron has email messaging preferences set but no email address, a message will be added to the message queue anyway, but will always end up 'failed'.

This could be resolved by modifying C4::Letters::enqueue to not enqueue call EnqueueLetter if the transport is email or sms and no to address is returned.
Comment 1 Kyle M Hall (khall) 2015-10-06 12:41:42 UTC Comment hidden (obsolete)
Comment 2 Kyle M Hall (khall) 2015-10-06 12:42:26 UTC
Created attachment 43162 [details] [review]
Bug 14964 - Email notices will be queued for patrons with no email address

If a patron has email messaging preferences set but no email address, a
message will be added to the message queue anyway, but will always end
up 'failed'.

This could be resolved by modifying C4::Letters::enqueue to not enqueue
call EnqueueLetter if the transport is email or sms and no to address is
returned.

Test Plan:
1) Set up patron with checkout messaging preference and no email address
2) Check out an item to the patron
3) Note the message in the message queue with no email address
4) Apply this patch
5) Check out an item to the patron
6) Note no message was queued this time
Comment 3 Marc Véron 2015-10-22 19:44:16 UTC
This functionality could be in conflict with:

Bug 12426 - Allow resending of emails from the notices tab in the patron account
Comment 4 Katrin Fischer 2015-10-22 20:23:08 UTC
Wondering... should we queue a message of the type 'print' if there is no e-mail address? I think this might be what we do for overdues
Comment 5 Katrin Fischer 2015-10-22 20:24:40 UTC
... but probably should be configurable - for some notices you might not want to have a printed one
Comment 6 Mark Tompsett 2015-10-28 14:12:34 UTC
I cringe at the lack of test coverage for C4::Message. *sigh*
Comment 7 Katrin Fischer 2025-09-11 11:49:35 UTC
This has become a little more "interesting" since in 24.11 the missing of an email addresses generates errors in the log instead of silently failing as before:

FAIL: No 'to_address', email address or guarantors email address for borrowernumber (4009) at /usr/share/koha/lib/C4/Letters.pm line 1417.

As we check regularly for problems with the crons this is currently creating quite a flood of email for us.
Comment 8 Lari Taskula 2026-02-03 11:32:27 UTC
(In reply to Katrin Fischer from comment #4)
> Wondering... should we queue a message of the type 'print' if there is no
> e-mail address? I think this might be what we do for overdues
> ... but probably should be configurable - for some notices you might not
> want to have a printed one

Definitely should be configurable. The volume of print messages could become massive if it was a mandatory fallback, and most of the patrons, though having no email address, would have enabled email notifications. It would happen when a library, that has enabled some default messaging preferences from the patron category, doesn't systemically collect patron email addresses.

If we absolutely must fallback to some type of messaging, I'd rather display them in OPAC notifications from Bug 36006.

I also remember developing code for messaging preferences where one could not check email messaging preferences before providing the email address, but it seems that functionality has not yet made it into Koha. (probably Bug 18595 patch (follow-up) Disable transports if missing contact information)