Summary: | Library no longer receiving Overdue email for patrons without email address | ||
---|---|---|---|
Product: | Koha | Reporter: | Katrin Fischer <katrin.fischer> |
Component: | Notices | Assignee: | Jonathan Druart <jonathan.druart> |
Status: | CLOSED FIXED | QA Contact: | Testopia <testopia> |
Severity: | critical | ||
Priority: | P5 - low | CC: | chris, dcook, fridolin.somers, gmcharlt, gwilliams, jonathan.druart, kyle, larry, nengard, tomascohen |
Version: | Main | Keywords: | regression |
Hardware: | All | ||
OS: | All | ||
See Also: | http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12810 | ||
Change sponsored?: | --- | Patch complexity: | Small patch |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: | |||
Bug Depends on: | 10832 | ||
Bug Blocks: | |||
Attachments: |
Bug 12717: Library no longer receiving Overdue email for patrons without email address
[SIGNED OFF] Bug 12717: Library no longer receiving Overdue email for patrons without email address [PASSED QA] Bug 12717: Library no longer receiving Overdue email for patrons without email address |
Description
Katrin Fischer
2014-08-04 15:31:13 UTC
The described behaviour is still in the documentation of overdue_notices.pl: http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=misc/cronjobs/overdue_notices.pl;h=943c4867c60041c33a6c7742fd8c0183ce9a3de7;hb=4e278782f156a9d7452e6e9ddcefee9542b964fc#l192 192 =head2 Outgoing emails 193 194 Typically, messages are prepared for each patron with overdue 195 items. Messages for whom there is no email address on file are 196 collected and sent as attachments in a single email to each library 197 administrator, or if that is not set, then to the email address in the 198 C<KohaAdminEmailAddress> system preference. (In reply to Katrin Fischer from comment #0) > With bug 10832 the handling of overdue emails has changes. Now if a patron > has no email address, there is a 'print' message generated. > > Before MTT was pushed overdues for patrons without email addresses would > automatically be sent to the library as an attachement to an email and could > be printed from there. > > I don't see how this can be done now, but I might be missing a configuration > option. Right now it looks like a regression for libraries not using server > generated files. I think there is also an issue with the former HOLD_PRINT notices as well. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10845#c37 Upgrading severity, this is a big issue for libraries in rural areas with many patrons who do not have email addresses. Ok,to make things worse, I am having trouble generating the files. I tried: overdue_notices.pl -html ./ Generates an empty HTML flie overdue_notices.pl -csv ./ Generates an CSV file with the header line, but no data gather_print_notices.pl ./ Generates a file named holdnotices-2014-08-16.html with my overdue letter ? This seems currently seriously broken. overdue_notices.pl -text ./ Empty txt file. BUT: -n will get -csv -html and -text working again. But it is NOT a solution, as it will not just grab the notices that are supposed to be printed, but will grab them all and no emails will be generated. From the documentation: -n Do not send any email. Overdue notices that would have been sent to the patrons or to the admin are printed to standard out. CSV data (if the -csv flag is set) is written to standard out or to any csv filename given. Still testing - one patron with email address and one without, both generating an overdue notice today. I think the options I tested before all work like they should, but they offer no solution to the problem. So I tried to make sure the old behaviour was as described. I found it working before the MTT changes, with: git checkout 9834401c59ed2ac41ca354732a528a117404fb76 ./misc/cronjobs/overdue_notices.pl (no parameters) Generates an email to the patron and one to the library with the text version as attachement. One of the differences between then and now is, that we now have an entry 'print' in the message_queue for the patrons without email. So we need to make sure that we can send an email with the overdue notices attached and set those enries to 'sent'. I will try to provide a fix soon. Created attachment 31022 [details] [review] Bug 12717: Library no longer receiving Overdue email for patrons without email address Bug 10832 changes the fallback behavior if a patron does not have email address: a print notice is generated into the message_queue table. But this can cause issue for some libraries. The script should sent an email and (generated csv, html, text file) with the list of all unsent notices. Test plan: 1/ Add overdue to a patron without email address (or smsalertnumber) 2/ Check email in the overdue rules configuration (or sms) 3/ Launch the overdue_notices.pl cronjob 4/ Verify the message_queue contain a print notice AND an email notice for the library (In reply to David Cook from comment #2) > I think there is also an issue with the former HOLD_PRINT notices as well. > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10845#c37 Could you please detail what could be wrong with HOLD? I realize a patch has already been written for this, but I'm wondering if this is the best way to go. For example, since gather_print_notices now seems to include all print notices, holds plus overdues, etc. (see bug 12810), and since Jonathan is working on a patch to get gather_print_notices to email files, maybe that should become that standard way of getting print notices, of all types, to the library staff. So, update gather_print_notices so that it's no longer "holds"-specific (i.e. stop naming the output file 'holdnotices...'), or possibly even have it output to different files depending on the type of notice. Then with the patch for bug 11678 in place, those would be emailed to the library, without the need to have the overdues cronjob email them. Something to consider. - Larry I think moving to a file based solution long term is good - but this was a feature libraries were relying to and I think we should bring it back AND work towards replacing it by gather_print_notices.pl long term. Right now the other script doesn't offer the same functionality and overdues.pl can already create different output formats. How I wish you could correct your bugzilla entries at times... Trying again to make more sense: I think moving to gather_print_notices.pl long term is good - but this is a feature libraries are relying on currently that got broken accidentally. I think we should bring it back for now AND work towards offering another option with gather_print_notices.pl. At the moment gather_print_notices.pl doesn't offer the same functionality and overdues.pl can already create different output formats. - I haven't tested the patch yet, but it looks rather small and I hope it will fix the problem. I agree with Katrin, lets get the accidentally removed functionality back, then work on extending the gather_print_notices to do the same. There are a lot of libraries using this, and if they upgraded from 3.14.x to 3.16.x would experience a regression that they may not even notice for a few days. Until they wondered, why arent we getting emails anymore .. and then its too late to send out the notices. Created attachment 31124 [details] [review] [SIGNED OFF] Bug 12717: Library no longer receiving Overdue email for patrons without email address Bug 10832 changes the fallback behavior if a patron does not have email address: a print notice is generated into the message_queue table. But this can cause issue for some libraries. The script should sent an email and (generated csv, html, text file) with the list of all unsent notices. Test plan: 1/ Add overdue to a patron without email address (or smsalertnumber) 2/ Check email in the overdue rules configuration (or sms) 3/ Launch the overdue_notices.pl cronjob 4/ Verify the message_queue contain a print notice AND an email notice for the library Signed-off-by: Nick Clemens <nick@quecheelibrary.org> I'm fine with restoring the functionality of overdues that was lost. However, we still need to address Bug 12810. Once this bug has been fixed, then a library that's also using gather_print_notices for holds will be getting multiple print overdue messages, one from overdues via email and another in the gather_print_notices output file. Regards, Larry Hi Larry, I agree. Having the overdues in the holdnotices file doesn't make sense and we need to make changes there as well. Created attachment 31163 [details] [review] [PASSED QA] Bug 12717: Library no longer receiving Overdue email for patrons without email address Bug 10832 changes the fallback behavior if a patron does not have email address: a print notice is generated into the message_queue table. But this can cause issue for some libraries. The script should sent an email and (generated csv, html, text file) with the list of all unsent notices. Test plan: 1/ Add overdue to a patron without email address (or smsalertnumber) 2/ Check email in the overdue rules configuration (or sms) 3/ Launch the overdue_notices.pl cronjob 4/ Verify the message_queue contain a print notice AND an email notice for the library Signed-off-by: Nick Clemens <nick@quecheelibrary.org> Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de> This works as described and restores the old behaviour for now, with the difference that you have a print notice generated and visible in the patron account notices tab that will say 'pending'. We will have to figure out how we can change the workflows nicely to have only one script deal with print notice in the future. What could be the next step? Things I can think off: - offer an option for the script not to send the email to the library, adjust the documentation in the script? - work on 11603 in order to make it possible to email files with gather_print_notices.pl? - add gather_print_notices.pl to the default cronjob files? - verify that gather_print_notices.pl can be set up to work similar/better than overduenotices now? Patch pushed to master. Thanks Jonathan! Pushed to 3.16.x for inclusion in 3.16.4. Bug 10832 is not in 3.14.x so this one is not needed. I set as resolved |