If an item is purchased from an online shop, the patron will receive a confirmation e-mail of their order. We would like to see something similar in Koha when a hold is placed. We think this would be useful to confirm some key points, for example: - confirm the hold has been added to the system - confirm the title details of the requested item - confirm the collection library - confirm the fee which will be charged for fulfilling the hold - confirm the fee which will be charged if the hold is not collected - explain how to cancel the hold if it's no longer required - explain how to make changes to the hold if any details (e.g. change collection library from AAA to BBB) alter - explain how the patron will be notified when the item is ready for collection There is already a system preference: emailLibrarianWhenHoldIsPlaced - which enables Koha to e-mail the library staff whenever a patron places a hold. Could the code behind this be adapted to e-mail patrons instead, perhaps?
*** Bug 35140 has been marked as a duplicate of this bug. ***
Created attachment 157961 [details] [review] Bug 17617: EmailPatronWhenHoldIsPlaced system preference
Created attachment 157962 [details] [review] Bug 17617: Add HOLDPLACED_PATRON notice A HOLDPLACED notice exists and is used by the emailLibrarianWhenHoldIsPlaced function, but libraries may want to use different wording when emailing patrons.
Created attachment 157963 [details] [review] Bug 17617: Unit tests
Created attachment 157964 [details] [review] Bug 17617: Confirmation email to patron when hold is placed This enhancement adds a new notice HOLDPLACED_PATRON that will be sent to a patron when a hold is placed for them. It depends on the new system preference EmailPatronWhenHoldIsPlaced to be enabled. To test: 1) Update database and restart services 2) Go to Koha Administration -> System preferences and search for the new EmailPatronWhenHoldIsPlaced syspref. It should be disabled by default - leave it disabled for now. 3) Search for a record and go to the Holds tab. Place a hold for your patron. 4) Go to your patron's account and go to the Notices tab. Confirm the HOLDPLACED_PATRON notice was NOT queued. 5) Enable the EmailPatronWhenHoldIsPlaced syspref. 6) Repeat steps 3 and 4. Confirm the HOLDPLACED_PATRON notice WAS generated and queued. 7) Confirm tests pass t/db_dependent/Holds.t Sponsored-by: Fire and Emergency New Zealand
Created attachment 157995 [details] [review] Bug 17617: EmailPatronWhenHoldIsPlaced system preference Signed-off-by: Kelly <kelly@bywatersolutions.com>
Created attachment 157996 [details] [review] Bug 17617: Add HOLDPLACED_PATRON notice A HOLDPLACED notice exists and is used by the emailLibrarianWhenHoldIsPlaced function, but libraries may want to use different wording when emailing patrons. Signed-off-by: Kelly <kelly@bywatersolutions.com>
Created attachment 157997 [details] [review] Bug 17617: Unit tests Signed-off-by: Kelly <kelly@bywatersolutions.com>
Created attachment 157998 [details] [review] Bug 17617: Confirmation email to patron when hold is placed This enhancement adds a new notice HOLDPLACED_PATRON that will be sent to a patron when a hold is placed for them. It depends on the new system preference EmailPatronWhenHoldIsPlaced to be enabled. To test: 1) Update database and restart services 2) Go to Koha Administration -> System preferences and search for the new EmailPatronWhenHoldIsPlaced syspref. It should be disabled by default - leave it disabled for now. 3) Search for a record and go to the Holds tab. Place a hold for your patron. 4) Go to your patron's account and go to the Notices tab. Confirm the HOLDPLACED_PATRON notice was NOT queued. 5) Enable the EmailPatronWhenHoldIsPlaced syspref. 6) Repeat steps 3 and 4. Confirm the HOLDPLACED_PATRON notice WAS generated and queued. 7) Confirm tests pass t/db_dependent/Holds.t Sponsored-by: Fire and Emergency New Zealand Signed-off-by: Kelly <kelly@bywatersolutions.com>
This is great, Aleisha - appreciate you working on this one. In addition to the system preference: Patrons can control whether they receive a hold collection notice via their messaging preferences. I wonder if they should also be allowed to opt out of these hold placed notices? We could open a new bug for it?
Created attachment 158310 [details] [review] Bug 17617: EmailPatronWhenHoldIsPlaced system preference Signed-off-by: Kelly <kelly@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 158311 [details] [review] Bug 17617: Add HOLDPLACED_PATRON notice A HOLDPLACED notice exists and is used by the emailLibrarianWhenHoldIsPlaced function, but libraries may want to use different wording when emailing patrons. Signed-off-by: Kelly <kelly@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 158312 [details] [review] Bug 17617: Unit tests Signed-off-by: Kelly <kelly@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 158313 [details] [review] Bug 17617: Confirmation email to patron when hold is placed This enhancement adds a new notice HOLDPLACED_PATRON that will be sent to a patron when a hold is placed for them. It depends on the new system preference EmailPatronWhenHoldIsPlaced to be enabled. To test: 1) Update database and restart services 2) Go to Koha Administration -> System preferences and search for the new EmailPatronWhenHoldIsPlaced syspref. It should be disabled by default - leave it disabled for now. 3) Search for a record and go to the Holds tab. Place a hold for your patron. 4) Go to your patron's account and go to the Notices tab. Confirm the HOLDPLACED_PATRON notice was NOT queued. 5) Enable the EmailPatronWhenHoldIsPlaced syspref. 6) Repeat steps 3 and 4. Confirm the HOLDPLACED_PATRON notice WAS generated and queued. 7) Confirm tests pass t/db_dependent/Holds.t Sponsored-by: Fire and Emergency New Zealand Signed-off-by: Kelly <kelly@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Just noting here that it might be good to test $patron->notice_email_address before enqueuing? Note that if SendQueuedMessages does not find an address, it will set status to failed in queue. No blocker.
Pushed to master for 23.11. Nice work everyone, thanks!
Enhancement not pushed to 23.05.x