Hi Mickey, 

there is currently no way to do a digest for hold notices. 

I think the idea is to let patrons know as fast as possible about holds being ready for pickup. I am not sure how a digest could work here. Maybe by circulation session? Summarize hold notices for a certain amount of time? I am not sure how hard it would be to implement something like this.

I am resetting the version to master, because this is an enhancement request for a future version.

This issues is also coming up for our library, as we regularly have patrons place holds on up to 50 items at a time (often with most of them being on shelf, and therefore getting a very large number of notices).  

As a possibility to realize this enhancement, consider treating reserves in the same way as overdues:  

    Create a new pl to merge the content of the pending reserves in the table at time of running the cronjob (will need a way to specify if a notice has been sent or not, e.g. new column notification_date, or something).  

    Create a new SysPref to either run as a cronjob (scheduled as the library sees fit, like other cronjobs), or in the way was previously done.  This would therefor require adding a check for this syspref to the existing perl which sends notifications.  

    Modify existing Holds notice template to list all items available, or make available the option to count the items.

Just an idea.  I have not really looked into doing this yet, so not sure how feasible it is, but we'll be looking a doing something, because the high volume of notices we are currently sending out is overwhelming some of our patrons (and we need to have the option to notify them when holds are available.

Maybe another idea for a possible solution would be to solve this similar to the checkout notices. For the first checkout the notice is created, for every checkout after that the notice is amended (I think) and then send out with the next run of the process_messaqueue job.

I would like to see this topic discussed or addressed.  This is an OLD issue, and it is still very relavant.  Not sure why it is not possible.  Maybe it is now?  Anyone?

I agree that the hold available notice should be digestable if possible.  The situation we have in our consortium is that patrons place requests on many titles held by other libraries.  Those libraries ship materials to the requesting library via our courier system.  When a box of materials arrives at the requesting library and there are 10 items in it that are all on hold for the same patron, those 10 items will all get checked in at the same time.  We have our system set to send hold available notices every 15 minutes, so what usually happens is that 15 minutes after a courier delivery, a patron who has requested 10 items from other libraries will get 10 SMS messages or 10 e-mails all at the exact same time.

I've seen this happen with as many as 30 messages sent simultaneously.  Patrons don't like getting 30 text messages all at once and if the messages are sent via e-mail in that high a quantity, they usually end up in the patron's spam folder.

(In reply to koha-US bug tracker from comment #5)
> I agree that the hold available notice should be digestable if possible. 
> The situation we have in our consortium is that patrons place requests on
> many titles held by other libraries.  Those libraries ship materials to the
> requesting library via our courier system.  When a box of materials arrives
> at the requesting library and there are 10 items in it that are all on hold
> for the same patron, those 10 items will all get checked in at the same
> time.  We have our system set to send hold available notices every 15
> minutes, so what usually happens is that 15 minutes after a courier
> delivery, a patron who has requested 10 items from other libraries will get
> 10 SMS messages or 10 e-mails all at the exact same time.
> 
> I've seen this happen with as many as 30 messages sent simultaneously. 
> Patrons don't like getting 30 text messages all at once and if the messages
> are sent via e-mail in that high a quantity, they usually end up in the
> patron's spam folder.

Yes!  And now this has an affect on text messaging and voice calls as well.

I think for phone ones, it might be better to talk to the vendor who does your phone calls, to see if they can change how they parse the file for calls to only call once if there are holds waiting.

This would be beneficial for the AspenCat Consortium - Bob Bennhoff

This would be great to have as an option. We often get patrons who are annoyed they are getting a ton of e-mails or texts that they have holds in. 

Would it be possible to send a digest of everything in a set period? We send out hold notices every 15 minutes so it would be nice if we could send out 1 digest every 15 minutes or something? We'd still like patrons to get notices quickly we just don't want them getting spammed. 

Lisette

This would be a great enhancement.  We get comments on the number of emails and text message the patrons receive.

(In reply to Lisette Scheer from comment #9)
> This would be great to have as an option. We often get patrons who are
> annoyed they are getting a ton of e-mails or texts that they have holds in. 
> 
> Would it be possible to send a digest of everything in a set period? We send
> out hold notices every 15 minutes so it would be nice if we could send out 1
> digest every 15 minutes or something? We'd still like patrons to get notices
> quickly we just don't want them getting spammed. 
> 
> Lisette

So, in theory, the regular hold notices would go out as frequent as it is set in it's own cron job, and then the digest would go out as frequent as it is set in a separate cron job. I would go for that.

Our patrons would definitely prefer a digest hold message over getting each one separately.

We would be interested in this enhancement.  Mary, Fletcher Free Library, VT

This seems to have died.  Would like to see this happen.  Notices have an impact on libraries, whether it is time spent with printed notices, spam blocks due to too many e-mails, blocks on text because of too many texts, or patrons getting too many phone calls.  Plus the added costs associated with each.

This really should be a priority.

I agree.

> This really should be a priority.

Just a note: we don't use the Importance field in bugzilla, so changing it will have no consequence. This is still an enhancement and I expect with no funding so far (noone assigned the bug, change sponsored empty, etc.).

> Just a note: we don't use the Importance field in bugzilla, so changing it
> will have no consequence. This is still an enhancement and I expect with no
> funding so far (noone assigned the bug, change sponsored empty, etc.)

Please don't read this as negative, I think it's important to have librarians on bugzilla comment on what is important and why. I am just a little worried that there is some kind of expectation here, that the community might be able to fulfill.

If it was a clear bug, things might be a little different about fixing it, but although it's a needed feature I think it does not quite qualify as a bug (vs being an enhancement)

*** Bug 21458 has been marked as a duplicate of this bug. ***

This is continuing to be a very popular request. Any idea how complex it would be to implement?

+1 ... we'd like to see this implemented as well.

A digest for Holds Pickup notices would also help with the issue of getting rate limited by email providers like Google.

Patrons getting notified that their holds are available for pickup is top priority for libraries.

See bug: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33360

We have numerous power users that have many holds arrive at the same time. A digest would help reduce a lot of miscommunication between the library and our patrons. In our opinion a crucial feature enhancement. 

Dan Lerch, Penticton Public Library

A digest option for holds ready for pickup across all methods, particularly phone would be greatly appreciated by our patrons at Cuyahoga County Public Library.

(In reply to Kristi from comment #23)
> A digest option for holds ready for pickup across all methods, particularly
> phone would be greatly appreciated by our patrons at Cuyahoga County Public
> Library.

+1

We totally support a digest of hold notifications at Benbrook Public Library!  This has been our number one complaint from patrons.  Thank you!

Created attachment 154947 [details] [review]
Bug 8838: Add digest option for HOLD notice

Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Restart all the things!
4) Enable the new digest option for "Hold filled" messages
5) Trap multiple holds for a patron
6) Note a single notices is generated for all the trapped holds!

Created attachment 154948 [details] [review]
Bug 8838: Add digest option for HOLD notice

Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Restart all the things!
4) Enable the new digest option for "Hold filled" messages
5) Trap multiple holds for a patron
6) Note a single notices is generated for all the trapped holds!

Created attachment 154950 [details] [review]
Bug 8838: Add digest option for HOLD notice

Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Restart all the things!
4) Enable the new digest option for "Hold filled" messages
5) Trap multiple holds for a patron
6) Note a single notices is generated for all the trapped holds!

Created attachment 154959 [details] [review]
Bug 8838: Add digest option for HOLD notice

Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Restart all the things!
4) Enable the new digest option for "Hold filled" messages
5) Trap multiple holds for a patron
6) Note a single notices is generated for all the trapped holds!

Created attachment 154969 [details] [review]
Bug 8838: Add digest option for HOLD notice

Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Restart all the things!
4) Enable the new digest option for "Hold filled" messages
5) Trap multiple holds for a patron
6) Note a single notices is generated for all the trapped holds!

Signed-off-by: George Williams <george@nekls.org>

Signed off on ByWater Sandbox.  Test plan works exactly as expected.

Created attachment 155415 [details] [review]
Bug 8838: Make db update idempotent

Created attachment 155487 [details] [review]
Bug 8838: Add digest option for HOLD notice

Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Restart all the things!
4) Enable the new digest option for "Hold filled" messages
5) Trap multiple holds for a patron
6) Note a single notices is generated for all the trapped holds!

Signed-off-by: George Williams <george@nekls.org>

Created attachment 155488 [details] [review]
Bug 8838: Make db update idempotent

Created attachment 155489 [details] [review]
Bug 8838: Add digest option for HOLD notice

Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Restart all the things!
4) Enable the new digest option for "Hold filled" messages
5) Trap multiple holds for a patron
6) Note a single notices is generated for all the trapped holds!

Signed-off-by: George Williams <george@nekls.org>

Created attachment 155490 [details] [review]
Bug 8838: Make db update idempotent

Created attachment 155504 [details] [review]
Bug 8838: Make db update idempotent

Signed-off-by: Laura ONeil <laura@bywatersolutions.com>

Created attachment 155505 [details] [review]
Bug 8838: Add digest option for HOLD notice

Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Restart all the things!
4) Enable the new digest option for "Hold filled" messages
5) Trap multiple holds for a patron
6) Note a single notices is generated for all the trapped holds!

Signed-off-by: George Williams <george@nekls.org>
Signed-off-by: Laura ONeil <laura@bywatersolutions.com>

Created attachment 155506 [details] [review]
Bug 8838: Make db update idempotent

Signed-off-by: Laura ONeil <laura@bywatersolutions.com>

Created attachment 155507 [details] [review]
Bug 8838: Replace the atomic update boilerplate

I noticed my local public library fills my holds and then I get an email the next day saying which holds are ready for me to pick up. I found the delay a bit annoying as I would've liked to know my holds were ready sooner, but I think having just 1 email was very nice.

Can you speak more to what the output would look like? If I understand correctly, it seems like the email body would contain two full email letters in it? 

If a patron did have 50 holds that were filled during different times of the day, I think they'd still get separate emails with the chunk being governed the interval that "process_message_queue.pl" runs?

(In reply to David Cook from comment #41)
> I noticed my local public library fills my holds and then I get an email the
> next day saying which holds are ready for me to pick up. I found the delay a
> bit annoying as I would've liked to know my holds were ready sooner, but I
> think having just 1 email was very nice.

This notice will function like the CHECKIN, CHECKOUT and RENEWAL notices. It will accrue until the message is sent, then start again. That means each library will be able to control 

(In reply to David Cook from comment #42)
> Can you speak more to what the output would look like? If I understand
> correctly, it seems like the email body would contain two full email letters
> in it?

This notice uses the same syntax as the above notices, only the middle section of the notice is repeated. The header and footer are not.

> If a patron did have 50 holds that were filled during different times of the
> day, I think they'd still get separate emails with the chunk being governed
> the interval that "process_message_queue.pl" runs?

That is correct. It'll behave just like the above notices. Another interesting thing to note is that the feature from bug 31453 means that libraries can run a separate process message queue cron for individual notices. The "default" run can go every $x minutes while another message queue cronjob for hold digests ( or checkin digests, or any other notice ) can run independently every $y minutes. It's not requisite but that feature gives libraries a lot more control over how long these digest notices build before being sent.

Excited to see this enhancement move forward!

Just a few fixes needed:

- reserves.t needs a minor rebase

- The update should include a default SMS notice as well, to prevent the worst-case scenario where a customer may not be notified of their waiting holds at all if the library doesn't specify an SMS template.


Plus a few trivial typoes, etc:

- Typo in the dbrev query to insert the default email template:
   Waiting since: [% hold.waitingdate %]:\r\n
   should be:
   Waiting since: [% hold.waitingdate %]\r\nWaitng at: [% hold.branch.branchname %]:\r\n

- Typo in sample_notices.yml line 1789 - "Waitng"

- Remember to tidy :)

Created attachment 157360 [details] [review]
Bug 8838: (follow-up) Rebase, fix typos, and tidy.

Thanks Emily, since Kyle is out and I'd like to see this move I went ahead and rebased, fixed typos, and tidied.

As for the SMS notice, I don't think there is any other notice in Koha where we add a default SMS template. I don't think we should start doing it now. 

Back to 'Signed-off'.

Thanks for the fixes, Lucas!

Looking at sample_notices.yml, there are 13 notices with a default SMS template, including the standard HOLD notice and most of the digest notices (with the exception of RENEWAL). My main concern is that if a library doesn't set up an SMS template for HOLDDGST, a customer could still check "SMS" and "Digest" as their messaging preference, and nothing would prevent it or alert them that they won't receive a notification with that selection.

Created attachment 157361 [details] [review]
Bug 8838: Add SMS default/sample notices

(In reply to Emily Lamancusa from comment #47)
> Thanks for the fixes, Lucas!
> 
> Looking at sample_notices.yml, there are 13 notices with a default SMS
> template, including the standard HOLD notice and most of the digest notices
> (with the exception of RENEWAL). My main concern is that if a library
> doesn't set up an SMS template for HOLDDGST, a customer could still check
> "SMS" and "Digest" as their messaging preference, and nothing would prevent
> it or alert them that they won't receive a notification with that selection.

You're right! I added those.

Created attachment 157456 [details] [review]
Bug 8838: Add digest option for HOLD notice

Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Restart all the things!
4) Enable the new digest option for "Hold filled" messages
5) Trap multiple holds for a patron
6) Note a single notices is generated for all the trapped holds!

Signed-off-by: George Williams <george@nekls.org>
Signed-off-by: Laura ONeil <laura@bywatersolutions.com>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>

Created attachment 157457 [details] [review]
Bug 8838: Make db update idempotent

Signed-off-by: Laura ONeil <laura@bywatersolutions.com>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>

Created attachment 157459 [details] [review]
Bug 8838: Replace the atomic update boilerplate

Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>

Created attachment 157460 [details] [review]
Bug 8838: (follow-up) Rebase, fix typos, and tidy.

Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>

Created attachment 157461 [details] [review]
Bug 8838: Add SMS default/sample notices

Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>

Created attachment 157462 [details] [review]
Bug 8838: (QA follow-up) one more typo fix

Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>

Awesome, thanks! Everything looks good now :)

Pushed to master for 23.11.

Nice work everyone, thanks!

Enhancement not pushed to 23.05.x

Such a long report should have great release notes ;)

(In reply to Fridolin Somers from comment #64)
> Enhancement not pushed to 23.05.x
> 
> Such a long report should have great release notes ;)

... and Documentation!