The ACCTDETAILS notice apparently bypasses message_queue; notices are sent directly to the linux mail queue. This may be useful from the standpoint that the message is sent immediately, but it should still be added to message_queue with status='sent', so that it's available when looking at the borrowers notices. --Barton
This is intentional as it is designed to send out clear text passwords (which might be debatable anyway).
So yeah, we can't just add it without more thought, but it would be nice to make it possible to see that one has been sent.
All alerts (that are sent directly and not queued in message_queue) are not displaid in notices. Should we have another way to store them or just had them to message_queue ?
I think I'd prefer "one place" for them. But we might need some adjustments. For example the list invites can be sent to arbitrary email addresses - so there is no account you'd see them from. maybe a view of the message queue somewhere - we use a report for that right now "messages sent out today" in our installations.
If we realize 27812 we could add it to the messagequeue after.
Created attachment 131165 [details] [review] Bug 17648: ACCTDETAILS notice does not show in notices.pl The ACCTDETAILS notice apparently bypasses message_queue; notices are sent directly to the linux mail queue. Test Plan: 1) Apply this patch 2) Create a new patron with an email address 3) Note the patron's ACCTDETAILS notice shows in the patron's messages
I don't we should do this before we have resolved bug 27812 that I have tried to give another push.
(In reply to Katrin Fischer from comment #7) > I don't we should do this before we have resolved bug 27812 that I have > tried to give another push. Agreed! I build this on top of 27812 so when I submitted my updated patches, this one got updated a couple minutes before that one :)
Created attachment 131199 [details] [review] Bug 17648: ACCTDETAILS notice does not show in notices.pl The ACCTDETAILS notice apparently bypasses message_queue; notices are sent directly to the linux mail queue. Test Plan: 1) Apply this patch 2) Create a new patron with an email address 3) Note the patron's ACCTDETAILS notice shows in the patron's messages Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 131200 [details] [review] Bug 17648: (QA follow-up) Further code cleaning We actually have a Koha::Patron method to do all the work of finding the right patron primary email address for notices.. we can use that here instead of doing it long hand.
Great improvement, all works ass expected.. Signing off
Created attachment 131202 [details] [review] Bug 17648: (QA follow-up) Restore imediate sending of the notice The original notice was sent using SendAlerts, which triggers immediately on submission and doesn't wait for the cron task. This patch restores that immediacy and also fixes a bug in the imports on the original patch.
Created attachment 131245 [details] [review] Bug 17648: (QA follow-up) Restore imediate sending of the notice The original notice was sent using SendAlerts, which triggers immediately on submission and doesn't wait for the cron task. This patch restores that immediacy and also fixes a bug in the imports on the original patch.
OK, this all works now.. but only with my followups as they fix the imports.. I decided not to doctor Kyles original patch ;)
Created attachment 131403 [details] [review] Bug 17648: ACCTDETAILS notice does not show in notices.pl The ACCTDETAILS notice apparently bypasses message_queue; notices are sent directly to the linux mail queue. Test Plan: 1) Apply this patch 2) Create a new patron with an email address 3) Note the patron's ACCTDETAILS notice shows in the patron's messages Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Created attachment 131404 [details] [review] Bug 17648: (QA follow-up) Further code cleaning We actually have a Koha::Patron method to do all the work of finding the right patron primary email address for notices.. we can use that here instead of doing it long hand. Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Created attachment 131405 [details] [review] Bug 17648: (QA follow-up) Restore imediate sending of the notice The original notice was sent using SendAlerts, which triggers immediately on submission and doesn't wait for the cron task. This patch restores that immediacy and also fixes a bug in the imports on the original patch. Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Pushed to master for 22.05, thanks to everybody involved [U+1F984]
Pushed to 21.11.x for 21.11.05