Add a link to allow resending a notice from the notices tab in the patron account. Sometimes the email address in the patron record is wrong and the library wants to resend the notices after correcting the email address.
Created attachment 42295 [details] [review] Bug 12426: Allow resending of messages from the notices tab in the patron account This patch adds a link 'Resend' under a notice in 'failed' status in the Patron's Notices tab. By clicking the link, we will request notices.pl with parameter "resendnotice=XXXXX" where XXXXX is message_id. In notices.pl, we then check whether the given message is actually in 'failed' status. If so, we use the C4::Letters::_set_message_status() to change the status of the message into 'pending'. This way it will be processed again by the cronjob process_message_queue.pl. To test, find/create a Patron that has failed notices in message_queue: 1. Enable EnchancedMessagingPreferences system preference 2. Go to Patrons -> Notices 3. In the Notice column, click the title of the failed message 4. Observe that there is nothing for resending the failed message 5. Apply patch. 6. Reload Notices page and repeat step 3 7. Observe that there is now a link "Resend" in the Status-column 8. Click Resend 9. Observe that the message gets into 'pending' status
Created attachment 42346 [details] [review] [Signed-off] Bug 12426: Allow resending of messages from the notices tab in the patron account This patch adds a link 'Resend' under a notice in 'failed' status in the Patron's Notices tab. By clicking the link, we will request notices.pl with parameter "resendnotice=XXXXX" where XXXXX is message_id. In notices.pl, we then check whether the given message is actually in 'failed' status. If so, we use the C4::Letters::_set_message_status() to change the status of the message into 'pending'. This way it will be processed again by the cronjob process_message_queue.pl. To test, find/create a Patron that has failed notices in message_queue: 1. Enable EnchancedMessagingPreferences system preference 2. Go to Patrons -> Notices 3. In the Notice column, click the title of the failed message 4. Observe that there is nothing for resending the failed message 5. Apply patch. 6. Reload Notices page and repeat step 3 7. Observe that there is now a link "Resend" in the Status-column 8. Click Resend 9. Observe that the message gets into 'pending' status Followed test plan. Works as expected. Signed-off-by: Marc Véron <veron@veron.ch>
Lari, I really would prefer to see a new subroutine added to C4::Letters covered by tests. Something like C4::Letters::ResendMessage($message_id).
Created attachment 42401 [details] [review] Bug 12426: Allow resending of messages from the notices tab in the patron account This patch adds a link 'Resend' under a notice in 'failed' status in the Patron's Notices tab. By clicking the link, we will request notices.pl with parameter "resendnotice=XXXXX" where XXXXX is message_id. In notices.pl, we then check whether the given message is actually in 'failed' status. If so, we use the C4::Letters::ResendMessage(123) to change the status of the message into 'pending'. This way it will be processed again by the cronjob process_message_queue.pl. To test, find/create a Patron that has failed notices in message_queue: 1. Enable EnchancedMessagingPreferences system preference 2. Go to Patrons -> Notices 3. In the Notice column, click the title of the failed message 4. Observe that there is nothing for resending the failed message 5. Apply patch. 6. Reload Notices page and repeat step 3 7. Observe that there is now a link "Resend" in the Status-column 8. Click Resend 9. Observe that the message gets into 'pending' status
Lari, is the first patch obsolete?
Marc, yes! Sorry, I forgot to do that. I made some modifications by Jonathan's wish.
Created attachment 42409 [details] [review] Bug 12426: Allow resending of messages from the notices tab in the patron account Changed return value of ResendMessage() to 1 on success, otherwise 0.
Created attachment 42418 [details] [review] [Signed-off] Bug 12426: Allow resending of messages from the notices tab in the patron account This patch adds a link 'Resend' under a notice in 'failed' status in the Patron's Notices tab. By clicking the link, we will request notices.pl with parameter "resendnotice=XXXXX" where XXXXX is message_id. In notices.pl, we then check whether the given message is actually in 'failed' status. If so, we use the C4::Letters::ResendMessage(123) to change the status of the message into 'pending'. This way it will be processed again by the cronjob process_message_queue.pl. To test, find/create a Patron that has failed notices in message_queue: 1. Enable EnchancedMessagingPreferences system preference 2. Go to Patrons -> Notices 3. In the Notice column, click the title of the failed message 4. Observe that there is nothing for resending the failed message 5. Apply patch. 6. Reload Notices page and repeat step 3 7. Observe that there is now a link "Resend" in the Status-column 8. Click Resend 9. Observe that the message gets into 'pending' status Works as expected. Signed-off-by: Marc Véron <veron@veron.ch>
Created attachment 42512 [details] [review] Bug 12426: Simplify the code adding a new subroutine GetMessage The C4::Letters module does not have a GetMessage subroutine, which could be quite useful. This patch adds it and simplifies the code added by the previous patch. It also adds a few tests and fixes POD typos. Note that ResendNotice only resends failed messages. This will avoid to resend already sent messages (using an url from the browser history for instance).
Lari, can I get your opinion on the second patch?
Jonathan, I agree we need indeed a way to get messages by id. In fact this will be very useful for me right now because of another bug that requires to get messages by id. Simplifying the code in notices.pl is well done. It is a good idea to move the status "failed" check into ResendMessage() so that it cannot be accidentally called for sent messages. I originally thought it would be up to the programmer to take care of the status check, and allow if he is sure he wants to resend a sent message, but I don't really see why anyone would want to do this. Maybe it is best to make the check inside ResendMessage(). Thanks for the help!
I think it could be very useful for a library to be able to resent messages that don't have a "failed" status - for example: the library has typoed in the email address. In this cases the email is sent, but bounced back to the library's email address (email account doesn't exist at this provider etc.) and it's up to the library to correct the email address. But the status will be sent. I have been asked a lot if there is a way to trigger a notice again - which is why I filed this bug :)
(In reply to Katrin Fischer from comment #12) > I think it could be very useful for a library to be able to resent messages > that don't have a "failed" status - for example: the library has typoed in > the email address. In this cases the email is sent, but bounced back to the > library's email address (email account doesn't exist at this provider etc.) > and it's up to the library to correct the email address. But the status will > be sent. > I have been asked a lot if there is a way to trigger a notice again - which > is why I filed this bug :) That's a very good point. For some reason I had been ignoring this :) With the current patch it is a bit risky, however. As Jonathan mentioned problems with browser history, (In reply to Jonathan Druart from comment #9) > Note that ResendNotice only resends failed messages. This will avoid to > resend already sent messages (using an url from the browser history for > instance). I suggest we change the method of request from GET and make it via AJAX calls to avoid problems caused by browser history. I have been working on REST API for Notices and have done all basic operations including resend. It would be nice to see this feature use the REST API via AJAX calls. Any support for this idea?
Hm not sure if I understand the browser history problem. Why would a link in the notices table to resend (with old fashioned reload or Ajax) not work?
Mostly asking because the REST API is not there yet - it would be nice if this small but great improvement would not be blocked by the bigger development.
(In reply to Lari Taskula from comment #13) > I suggest we change the method of request from GET and make it via AJAX > calls to avoid problems caused by browser history. I have been working on > REST API for Notices and have done all basic operations including resend. It > would be nice to see this feature use the REST API via AJAX calls. Any > support for this idea? (In reply to Katrin Fischer from comment #15) > Mostly asking because the REST API is not there yet - it would be nice if > this small but great improvement would not be blocked by the bigger > development. Exactly what I was going to answer :)
(In reply to Katrin Fischer from comment #14) > Hm not sure if I understand the browser history problem. Why would a link in > the notices table to resend (with old fashioned reload or Ajax) not work? Clicking on the resend link, will call /cgi-bin/koha/script.pl?op=resend&message_id=42 (or equivalent). If you don't limit the resend to fail messages, a user could unexpectedly recall this url, and resend again the message.
So AJAX call or via POST could solved the issue
Katrin, As Jonathan mentioned, AJAX would work fine but (with current patch) the following link cgi-bin/koha/members/notices.pl?borrowernumber=1&resendnotice=4 would stay in your browser history. Let's imagine we clicked the link and the message was resent perfectly fine and we want to forget about it. But since it's in the browser history, a staff member can accidentally get back on this page by using the address bar, without realizing that this will resend the message once again. And yes, I understand your concern - it is very problematic that it would be blocked by the REST API since it's not there yet. So what would be the point to use it for such a small feature? But here we are very optimistic and excited about the REST API. I think it is a great opportunity to keep pushing it forward by making features already dependant on it. To use this nice feature you would need to use the REST API - great way to encourage other people to check it out and learn about it :)
Everyone is very excited - but woudl be good to have at least the base patches in Koha first.
(In reply to Lari Taskula from comment #19) > But here we are very optimistic and excited about the REST API. I think it > is a great opportunity to keep pushing it forward by making features already > dependant on it. To use this nice feature you would need to use the REST API > - great way to encourage other people to check it out and learn about it :) I personally just mark these patches as BLOCKED since the base is not accepted/validated/etc. It just makes me think "this work will have to rebase for ages".
Would a possible compromise be, accept as is without using the REST API and without being able to resend failed messages? With the understanding that a new bug # be created that enhances this one by using the REST API? That way the functionality libraries have been looking for more then a year is added.
Hi Misilo, I think failed will only cover a really small percentage. I think making it work for all status using a POST could be a little nicer.
Created attachment 42615 [details] [review] Bug 12426: Allow resend for sent messages This patch allows to resend both sent and failed messages. With messages in 'sent' status, we have to be careful not to accidentally send sent messages again. With the previous patch using GET request, this was likely to happen because of browser storing the GET parameters. This patch changes request method from GET to POST. Instead of a simple link, we now have a form element. In notices.pl we redirect back to notices.pl, because with POST there is a risk of resending the message accidentally by form resubmission at refresh. To test, find/create a Patron that has failed notices in message_queue: 1. Enable EnchancedMessagingPreferences system preference 2. Go to Patrons -> Notices 3. In the Notice column, click the title of the failed message 4. Observe that there is nothing for resending the failed message 5. Apply patch. 6. Reload Notices page and repeat step 3 7. Observe that there is now a link "Resend" in the Status-column 8. Click Resend 9. Observe that the message gets into 'pending' status
Created attachment 42618 [details] [review] Bug 12426: Allow resend for sent messages To test, find/create a Patron that has sent or failed notices in message_queue: 1. Enable EnchancedMessagingPreferences system preference 2. Go to Patrons -> Notices 3. In the Notice column, click the title of the sent or failed message 4. Observe that there is nothing for resending the sent or failed message 5. Apply the patches. 6. Reload Notices page and repeat step 3 7. Observe that there is now a link "Resend" in the Status-column 8. Click Resend 9. Observe that the message gets into 'pending' status
Comment on attachment 42618 [details] [review] Bug 12426: Allow resend for sent messages Review of attachment 42618 [details] [review]: ----------------------------------------------------------------- + Your patch introduces trailing whitespaces. ::: members/notices.pl @@ +58,5 @@ > my $message = C4::Letters::GetMessage( $message_id ); > if ( $message->{borrowernumber} = $borrowernumber ) { > C4::Letters::ResendMessage( $message_id ); > + # redirect to self to avoid form submission on refresh > + print $input->redirect("/cgi-bin/koha/members/notices.pl?borrowernumber=$borrowernumber"); Not sure this is useful, what will happen if the form is resubmit? That will change the status from pending to pending? :) ::: t/db_dependent/Letters.t @@ +18,4 @@ > # along with Koha; if not, see <http://www.gnu.org/licenses>. > > use Modern::Perl; > +use Test::More tests => 68; I'd say we can keep the test you have removed, and adapt it. So we check a message can be resend independently of its status.
(I should reread my comments before sending them...)
(In reply to Jonathan Druart from comment #26) > Comment on attachment 42618 [details] [review] [review] > Bug 12426: Allow resend for sent messages > > Review of attachment 42618 [details] [review] [review]: > ----------------------------------------------------------------- > > + Your patch introduces trailing whitespaces. > > ::: members/notices.pl > @@ +58,5 @@ > > my $message = C4::Letters::GetMessage( $message_id ); > > if ( $message->{borrowernumber} = $borrowernumber ) { > > C4::Letters::ResendMessage( $message_id ); > > + # redirect to self to avoid form submission on refresh > > + print $input->redirect("/cgi-bin/koha/members/notices.pl?borrowernumber=$borrowernumber"); > > Not sure this is useful, what will happen if the form is resubmit? > That will change the status from pending to pending? :) Without this, when refreshing the page, the browser will ask for resending the form. Some staff member can click refresh to see if the resent message is now in sent status and accidentally put it for resend once again. When we redirect back to notices.pl, form cannot be resent again (at least this was the behavior on my Firefox) even if he/she clicks refresh. It will simply refresh the page without asking/sending any form data again. > ::: t/db_dependent/Letters.t > @@ +18,4 @@ > > # along with Koha; if not, see <http://www.gnu.org/licenses>. > > > > use Modern::Perl; > > +use Test::More tests => 68; > > I'd say we can keep the test you have removed, and adapt it. > So we check a message can be resend independently of its status. Okay, I'll update it.
Hm one idea - should we exclude pending from being resent?
Created attachment 42620 [details] [review] Bug 12426: Allow resend for sent messages Keeps the test and checks that resend is successful regardless of message status.
Created attachment 42621 [details] [review] Bug 12426: Allow resend for sent messages Doesn't allow resend for pending messages. It does not make sense. Also keep Jonathan's original tests as they were.
Would be really nice to see a sign-off for this asap! Please?
I'm sorry, conflict with first patch: CONFLICT (content): Merge conflict in t/db_dependent/Letters.t
Created attachment 47563 [details] [review] [Signed-off] Bug 12426: Allow resending of messages from the notices tab in the patron account This patch adds a link 'Resend' under a notice in 'failed' status in the Patron's Notices tab. By clicking the link, we will request notices.pl with parameter "resendnotice=XXXXX" where XXXXX is message_id. In notices.pl, we then check whether the given message is actually in 'failed' status. If so, we use the C4::Letters::ResendMessage(123) to change the status of the message into 'pending'. This way it will be processed again by the cronjob process_message_queue.pl. To test, find/create a Patron that has failed notices in message_queue: 1. Enable EnchancedMessagingPreferences system preference 2. Go to Patrons -> Notices 3. In the Notice column, click the title of the failed message 4. Observe that there is nothing for resending the failed message 5. Apply patch. 6. Reload Notices page and repeat step 3 7. Observe that there is now a link "Resend" in the Status-column 8. Click Resend 9. Observe that the message gets into 'pending' status Works as expected. Signed-off-by: Marc Véron <veron@veron.ch>
Created attachment 47564 [details] [review] Bug 12426: Simplify the code adding a new subroutine GetMessage The C4::Letters module does not have a GetMessage subroutine, which could be quite useful. This patch adds it and simplifies the code added by the previous patch. It also adds a few tests and fixes POD typos. Note that ResendNotice only resends failed messages. This will avoid to resend already sent messages (using an url from the browser history for instance).
Created attachment 47565 [details] [review] Bug 12426: Allow resend for sent messages This patch allows to resend both sent and failed messages. With messages in 'sent' status, we have to be careful not to accidentally send sent messages again. With the previous patch using GET request, this was likely to happen because of browser storing the GET parameters. This patch changes request method from GET to POST. Instead of a simple link, we now have a form element. In notices.pl we redirect back to notices.pl, because with POST there is a risk of resending the message accidentally by form resubmission at refresh. To test, find/create a Patron that has sent or failed notices in message_queue: 1. Enable EnchancedMessagingPreferences system preference 2. Go to Patrons -> Notices 3. In the Notice column, click the title of the sent or failed message 4. Observe that there is nothing for resending the sent or failed message 5. Apply the patches. 6. Reload Notices page and repeat step 3 7. Observe that there is now a link "Resend" in the Status-column 8. Click Resend 9. Observe that the message gets into 'pending' status
Except for moving the $op line, this is a rebase, which applies. I have not signed off. The sign off change is identical, so I left it marked as such.
Created attachment 47588 [details] [review] Bug 12426: Allow resending of messages from the notices tab in the patron account This patch adds a link 'Resend' under a notice in 'failed' status in the Patron's Notices tab. By clicking the link, we will request notices.pl with parameter "resendnotice=XXXXX" where XXXXX is message_id. In notices.pl, we then check whether the given message is actually in 'failed' status. If so, we use the C4::Letters::ResendMessage(123) to change the status of the message into 'pending'. This way it will be processed again by the cronjob process_message_queue.pl. To test, find/create a Patron that has failed notices in message_queue: 1. Enable EnchancedMessagingPreferences system preference 2. Go to Patrons -> Notices 3. In the Notice column, click the title of the failed message 4. Observe that there is nothing for resending the failed message 5. Apply patch. 6. Reload Notices page and repeat step 3 7. Observe that there is now a link "Resend" in the Status-column 8. Click Resend 9. Observe that the message gets into 'pending' status Works as expected. Signed-off-by: Marc Véron <veron@veron.ch>
Created attachment 47589 [details] [review] Bug 12426: Simplify the code adding a new subroutine GetMessage The C4::Letters module does not have a GetMessage subroutine, which could be quite useful. This patch adds it and simplifies the code added by the previous patch. It also adds a few tests and fixes POD typos. Note that ResendNotice only resends failed messages. This will avoid to resend already sent messages (using an url from the browser history for instance).
Created attachment 47590 [details] [review] Bug 12426: Allow resend for sent messages This patch allows to resend both sent and failed messages. With messages in 'sent' status, we have to be careful not to accidentally send sent messages again. With the previous patch using GET request, this was likely to happen because of browser storing the GET parameters. This patch changes request method from GET to POST. Instead of a simple link, we now have a form element. In notices.pl we redirect back to notices.pl, because with POST there is a risk of resending the message accidentally by form resubmission at refresh. To test, find/create a Patron that has sent or failed notices in message_queue: 1. Enable EnchancedMessagingPreferences system preference 2. Go to Patrons -> Notices 3. In the Notice column, click the title of the sent or failed message 4. Observe that there is nothing for resending the sent or failed message 5. Apply the patches. 6. Reload Notices page and repeat step 3 7. Observe that there is now a link "Resend" in the Status-column 8. Click Resend 9. Observe that the message gets into 'pending' status Tested all patches together. Wors as expected. Signed-off-by: Marc Véron <veron@veron.ch>
QA: Looking at this one now.
Created attachment 47956 [details] [review] Bug 12426: Allow resending of messages from the notices tab in the patron account This patch adds a link 'Resend' under a notice in 'failed' status in the Patron's Notices tab. By clicking the link, we will request notices.pl with parameter "resendnotice=XXXXX" where XXXXX is message_id. In notices.pl, we then check whether the given message is actually in 'failed' status. If so, we use the C4::Letters::ResendMessage(123) to change the status of the message into 'pending'. This way it will be processed again by the cronjob process_message_queue.pl. To test, find/create a Patron that has failed notices in message_queue: 1. Enable EnchancedMessagingPreferences system preference 2. Go to Patrons -> Notices 3. In the Notice column, click the title of the failed message 4. Observe that there is nothing for resending the failed message 5. Apply patch. 6. Reload Notices page and repeat step 3 7. Observe that there is now a link "Resend" in the Status-column 8. Click Resend 9. Observe that the message gets into 'pending' status Works as expected. Signed-off-by: Marc Veron <veron@veron.ch> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 47957 [details] [review] Bug 12426: Simplify the code adding a new subroutine GetMessage The C4::Letters module does not have a GetMessage subroutine, which could be quite useful. This patch adds it and simplifies the code added by the previous patch. It also adds a few tests and fixes POD typos. Note that ResendNotice only resends failed messages. This will avoid to resend already sent messages (using an url from the browser history for instance). Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 47958 [details] [review] Bug 12426: Allow resend for sent messages This patch allows to resend both sent and failed messages. With messages in 'sent' status, we have to be careful not to accidentally send sent messages again. With the previous patch using GET request, this was likely to happen because of browser storing the GET parameters. This patch changes request method from GET to POST. Instead of a simple link, we now have a form element. In notices.pl we redirect back to notices.pl, because with POST there is a risk of resending the message accidentally by form resubmission at refresh. To test, find/create a Patron that has sent or failed notices in message_queue: 1. Enable EnchancedMessagingPreferences system preference 2. Go to Patrons -> Notices 3. In the Notice column, click the title of the sent or failed message 4. Observe that there is nothing for resending the sent or failed message 5. Apply the patches. 6. Reload Notices page and repeat step 3 7. Observe that there is now a link "Resend" in the Status-column 8. Click Resend 9. Observe that the message gets into 'pending' status Tested all patches together. Works as expected. Signed-off-by: Marc Veron <veron@veron.ch> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Perhaps we could also think about clearing the to_address and reading it again (as is done in SendQueuedLetters already). You could have adjusted the patron's email address (possible trigger for resending an email) and now you want to resend to the new/corrected email address.
Ah, I thought it always rechecked before sending it - maybe in another piece of code?
(In reply to Marcel de Rooy from comment #45) > Perhaps we could also think about clearing the to_address and reading it > again (as is done in SendQueuedLetters already). > > You could have adjusted the patron's email address (possible trigger for > resending an email) and now you want to resend to the new/corrected email > address. That's a very good remark and the expected behavior. IMO it should be a requirement for this patch to be pushed (as it's very easy to implement). (In reply to Katrin Fischer from comment #46) > Ah, I thought it always rechecked before sending it - maybe in another piece > of code? Usually the to_address is not set when inserting the message to the message queue. The _send_message_by_email get the patron's email address only if the message does not have one.
Created attachment 48049 [details] [review] Bug 12426: [QA Follow-up] Clear to_address to force update When resending an email from the Notices tab in Patrons, we would like to use the recent email address. Test plan: [1] Look up a patron with some notices sent. [2] Adjust the patron email address (watch AutoEmailPrimaryAddress). [3] Resend the notice. Verify if the new address was used. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
(In reply to Jonathan Druart from comment #47) > That's a very good remark and the expected behavior. > IMO it should be a requirement for this patch to be pushed (as it's very > easy to implement). OK. Added a follow-up. Thx
Didn't apply cleanly - I know because of the moving target that master is. Please rebase. Once it's done - leave me an @later in #koha and I'll jump right on it. Thank you so much for the time and bother of rebasing. Brendan
Created attachment 48570 [details] [review] Bug 12426: Allow resending of messages from the notices tab in the patron account This patch adds a link 'Resend' under a notice in 'failed' status in the Patron's Notices tab. By clicking the link, we will request notices.pl with parameter "resendnotice=XXXXX" where XXXXX is message_id. In notices.pl, we then check whether the given message is actually in 'failed' status. If so, we use the C4::Letters::ResendMessage(123) to change the status of the message into 'pending'. This way it will be processed again by the cronjob process_message_queue.pl. To test, find/create a Patron that has failed notices in message_queue: 1. Enable EnchancedMessagingPreferences system preference 2. Go to Patrons -> Notices 3. In the Notice column, click the title of the failed message 4. Observe that there is nothing for resending the failed message 5. Apply patch. 6. Reload Notices page and repeat step 3 7. Observe that there is now a link "Resend" in the Status-column 8. Click Resend 9. Observe that the message gets into 'pending' status Works as expected. Signed-off-by: Marc Véron <veron@veron.ch>
Created attachment 48571 [details] [review] Bug 12426: Simplify the code adding a new subroutine GetMessage The C4::Letters module does not have a GetMessage subroutine, which could be quite useful. This patch adds it and simplifies the code added by the previous patch. It also adds a few tests and fixes POD typos. Note that ResendNotice only resends failed messages. This will avoid to resend already sent messages (using an url from the browser history for instance).
Created attachment 48572 [details] [review] Bug 12426: Allow resend for sent messages This patch allows to resend both sent and failed messages. With messages in 'sent' status, we have to be careful not to accidentally send sent messages again. With the previous patch using GET request, this was likely to happen because of browser storing the GET parameters. This patch changes request method from GET to POST. Instead of a simple link, we now have a form element. In notices.pl we redirect back to notices.pl, because with POST there is a risk of resending the message accidentally by form resubmission at refresh. To test, find/create a Patron that has sent or failed notices in message_queue: 1. Enable EnchancedMessagingPreferences system preference 2. Go to Patrons -> Notices 3. In the Notice column, click the title of the sent or failed message 4. Observe that there is nothing for resending the sent or failed message 5. Apply the patches. 6. Reload Notices page and repeat step 3 7. Observe that there is now a link "Resend" in the Status-column 8. Click Resend 9. Observe that the message gets into 'pending' status
Created attachment 48573 [details] [review] Bug 12426: [QA Follow-up] Clear to_address to force update When resending an email from the Notices tab in Patrons, we would like to use the recent email address. Test plan: [1] Look up a patron with some notices sent. [2] Adjust the patron email address (watch AutoEmailPrimaryAddress). [3] Resend the notice. Verify if the new address was used. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Sorry, Marcel, my rebase lost your sign-off markers at the end of the files.
Putting this back where it came from (PQA) Any reason why you moved this back to SO, Mark? If it was a hard rebase, getting another signoff should imo go via NSO.
(In reply to Marcel de Rooy from comment #56) > Putting this back where it came from (PQA) > Any reason why you moved this back to SO, Mark? > If it was a hard rebase, getting another signoff should imo go via NSO. Because I wasn't sure what status I should move it to, but it wasn't hard. And your sign-offs were lost, because I didn't have them to start, and I forgot to add them.
Pushed to Master - Should be in the May 2016 release. Thanks!