Bug 8838 - Digest option for HOLD notice
Summary: Digest option for HOLD notice
Status: Needs documenting
Alias: None
Product: Koha
Classification: Unclassified
Component: Notices (show other bugs)
Version: Main
Hardware: All All
: P1 - high enhancement with 64 votes (vote)
Assignee: Kyle M Hall
QA Contact: Emily Lamancusa
URL:
Keywords:
: 21458 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-09-27 15:06 UTC by Mickey Coalwell
Modified: 2023-11-30 16:18 UTC (History)
36 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
This adds a digest checkbox for "Hold filled" in the messaging preferences settings. When checked, all pickup notices for holds will be collected and send out in a single notice. The letter used is `HOLDDGST`.
Version(s) released in:
23.11.00


Attachments
Bug 8838: Add digest option for HOLD notice (6.77 KB, patch)
2023-08-30 11:10 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 8838: Add digest option for HOLD notice (6.78 KB, patch)
2023-08-30 11:11 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 8838: Add digest option for HOLD notice (7.57 KB, patch)
2023-08-30 11:37 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 8838: Add digest option for HOLD notice (11.06 KB, patch)
2023-08-30 13:55 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 8838: Add digest option for HOLD notice (11.10 KB, patch)
2023-08-30 14:51 UTC, ByWater Sandboxes
Details | Diff | Splinter Review
Bug 8838: Make db update idempotent (2.17 KB, patch)
2023-09-08 13:35 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 8838: Add digest option for HOLD notice (10.97 KB, patch)
2023-09-11 13:20 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 8838: Make db update idempotent (2.17 KB, patch)
2023-09-11 13:20 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 8838: Add digest option for HOLD notice (11.11 KB, patch)
2023-09-11 13:28 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 8838: Make db update idempotent (2.17 KB, patch)
2023-09-11 13:29 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 8838: Make db update idempotent (2.22 KB, patch)
2023-09-11 16:27 UTC, ByWater Sandboxes
Details | Diff | Splinter Review
Bug 8838: Add digest option for HOLD notice (11.15 KB, patch)
2023-09-11 16:32 UTC, ByWater Sandboxes
Details | Diff | Splinter Review
Bug 8838: Make db update idempotent (2.22 KB, patch)
2023-09-11 16:32 UTC, ByWater Sandboxes
Details | Diff | Splinter Review
Bug 8838: Replace the atomic update boilerplate (1.14 KB, patch)
2023-09-11 17:44 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 8838: (follow-up) Rebase, fix typos, and tidy. (8.60 KB, patch)
2023-10-18 21:06 UTC, Lucas Gass
Details | Diff | Splinter Review
Bug 8838: Add SMS default/sample notices (3.24 KB, patch)
2023-10-18 22:32 UTC, Lucas Gass
Details | Diff | Splinter Review
Bug 8838: Add digest option for HOLD notice (11.15 KB, patch)
2023-10-19 14:21 UTC, Emily Lamancusa
Details | Diff | Splinter Review
Bug 8838: Make db update idempotent (2.22 KB, patch)
2023-10-19 14:21 UTC, Emily Lamancusa
Details | Diff | Splinter Review
Bug 8838: Replace the atomic update boilerplate (1.14 KB, patch)
2023-10-19 14:21 UTC, Emily Lamancusa
Details | Diff | Splinter Review
Bug 8838: (follow-up) Rebase, fix typos, and tidy. (8.59 KB, patch)
2023-10-19 14:21 UTC, Emily Lamancusa
Details | Diff | Splinter Review
Bug 8838: Add SMS default/sample notices (3.24 KB, patch)
2023-10-19 14:21 UTC, Emily Lamancusa
Details | Diff | Splinter Review
Bug 8838: (QA follow-up) one more typo fix (1.92 KB, patch)
2023-10-19 14:21 UTC, Emily Lamancusa
Details | Diff | Splinter Review
Bug 8838: Add digest option for HOLD notice (11.22 KB, patch)
2023-10-19 14:23 UTC, Emily Lamancusa
Details | Diff | Splinter Review
Bug 8838: Make db update idempotent (2.29 KB, patch)
2023-10-19 14:23 UTC, Emily Lamancusa
Details | Diff | Splinter Review
Bug 8838: Replace the atomic update boilerplate (1.21 KB, patch)
2023-10-19 14:23 UTC, Emily Lamancusa
Details | Diff | Splinter Review
Bug 8838: (follow-up) Rebase, fix typos, and tidy. (8.66 KB, patch)
2023-10-19 14:23 UTC, Emily Lamancusa
Details | Diff | Splinter Review
Bug 8838: Add SMS default/sample notices (3.31 KB, patch)
2023-10-19 14:23 UTC, Emily Lamancusa
Details | Diff | Splinter Review
Bug 8838: (QA follow-up) one more typo fix (1.99 KB, patch)
2023-10-19 14:23 UTC, Emily Lamancusa
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Mickey Coalwell 2012-09-27 15:06:40 UTC
Is there a way to set Koha to only send one email to a patron when they have several items on hold instead of one email for each item? We've had a couple of patrons ask and 12 emails put a patron over her email inbox quota.

Thanks,
Erica Voell
Bonner Springs City Library
Comment 1 Katrin Fischer 2012-09-28 12:08:20 UTC
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.
Comment 2 dmin 2014-08-21 13:56:59 UTC
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.
Comment 3 Katrin Fischer 2014-08-23 17:26:48 UTC
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.
Comment 4 Christopher Brannon 2019-09-21 19:26:38 UTC
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?
Comment 5 koha-US bug tracker 2019-09-21 19:30:52 UTC
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.
Comment 6 Christopher Brannon 2019-09-21 19:47:45 UTC
(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.
Comment 7 Liz Rea 2019-11-06 16:00:28 UTC
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.
Comment 8 AspenCat Team 2020-03-11 15:53:16 UTC
This would be beneficial for the AspenCat Consortium - Bob Bennhoff
Comment 9 Lisette Scheer 2020-06-10 16:24:44 UTC
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
Comment 10 Rhonda Kuiper 2020-06-10 16:36:54 UTC
This would be a great enhancement.  We get comments on the number of emails and text message the patrons receive.
Comment 11 Christopher Brannon 2020-06-10 17:39:14 UTC
(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.
Comment 12 Barbara Johnson 2020-07-17 16:40:27 UTC
Our patrons would definitely prefer a digest hold message over getting each one separately.
Comment 13 mdanko 2021-07-07 20:53:45 UTC
We would be interested in this enhancement.  Mary, Fletcher Free Library, VT
Comment 14 Christopher Brannon 2022-02-25 17:58:16 UTC
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.
Comment 15 Michal Denar 2022-02-25 21:29:32 UTC
I agree.
Comment 16 Katrin Fischer 2022-02-26 13:18:29 UTC
> 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.).
Comment 17 Katrin Fischer 2022-02-26 13:22:48 UTC
> 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)
Comment 18 Nick Clemens 2022-09-20 20:37:19 UTC
*** Bug 21458 has been marked as a duplicate of this bug. ***
Comment 19 Donna 2023-01-26 15:22:43 UTC
This is continuing to be a very popular request. Any idea how complex it would be to implement?
Comment 20 Christofer Zorn 2023-03-30 16:45:54 UTC
+1 ... we'd like to see this implemented as well.
Comment 21 Brendan Lawlor 2023-05-17 14:30:20 UTC
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
Comment 22 Dan Lerch 2023-06-14 16:14:10 UTC
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
Comment 23 Kristi 2023-06-14 18:10:51 UTC
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.
Comment 24 Christopher Brannon 2023-06-14 19:26:44 UTC
(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
Comment 25 Erica 2023-06-15 14:20:36 UTC
We totally support a digest of hold notifications at Benbrook Public Library!  This has been our number one complaint from patrons.  Thank you!
Comment 26 Kyle M Hall 2023-08-30 11:10:29 UTC
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!
Comment 27 Kyle M Hall 2023-08-30 11:11:05 UTC
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!
Comment 28 Kyle M Hall 2023-08-30 11:37:31 UTC
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!
Comment 29 Kyle M Hall 2023-08-30 13:55:20 UTC
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!
Comment 30 ByWater Sandboxes 2023-08-30 14:51:41 UTC
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>
Comment 31 George Williams (NEKLS) 2023-08-30 14:52:49 UTC
Signed off on ByWater Sandbox.  Test plan works exactly as expected.
Comment 32 Kyle M Hall 2023-09-08 13:35:31 UTC
Created attachment 155415 [details] [review]
Bug 8838: Make db update idempotent
Comment 33 Kyle M Hall 2023-09-11 13:20:45 UTC
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>
Comment 34 Kyle M Hall 2023-09-11 13:20:54 UTC
Created attachment 155488 [details] [review]
Bug 8838: Make db update idempotent
Comment 35 Kyle M Hall 2023-09-11 13:28:49 UTC
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>
Comment 36 Kyle M Hall 2023-09-11 13:29:02 UTC
Created attachment 155490 [details] [review]
Bug 8838: Make db update idempotent
Comment 37 ByWater Sandboxes 2023-09-11 16:27:59 UTC
Created attachment 155504 [details] [review]
Bug 8838: Make db update idempotent

Signed-off-by: Laura ONeil <laura@bywatersolutions.com>
Comment 38 ByWater Sandboxes 2023-09-11 16:32:37 UTC
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>
Comment 39 ByWater Sandboxes 2023-09-11 16:32:42 UTC
Created attachment 155506 [details] [review]
Bug 8838: Make db update idempotent

Signed-off-by: Laura ONeil <laura@bywatersolutions.com>
Comment 40 Kyle M Hall 2023-09-11 17:44:26 UTC
Created attachment 155507 [details] [review]
Bug 8838: Replace the atomic update boilerplate
Comment 41 David Cook 2023-09-12 01:59:50 UTC
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.
Comment 42 David Cook 2023-09-12 02:05:13 UTC
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?
Comment 43 Kyle M Hall 2023-10-13 16:07:13 UTC
(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.
Comment 44 Emily Lamancusa 2023-10-18 17:08:38 UTC
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 :)
Comment 45 Lucas Gass 2023-10-18 21:06:58 UTC
Created attachment 157360 [details] [review]
Bug 8838: (follow-up) Rebase, fix typos, and tidy.
Comment 46 Lucas Gass 2023-10-18 21:09:16 UTC
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'.
Comment 47 Emily Lamancusa 2023-10-18 21:29:23 UTC
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.
Comment 48 Lucas Gass 2023-10-18 22:32:14 UTC
Created attachment 157361 [details] [review]
Bug 8838: Add SMS default/sample notices
Comment 49 Lucas Gass 2023-10-18 22:33:39 UTC
(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.
Comment 50 Emily Lamancusa 2023-10-19 14:21:06 UTC Comment hidden (obsolete)
Comment 51 Emily Lamancusa 2023-10-19 14:21:11 UTC Comment hidden (obsolete)
Comment 52 Emily Lamancusa 2023-10-19 14:21:15 UTC Comment hidden (obsolete)
Comment 53 Emily Lamancusa 2023-10-19 14:21:20 UTC Comment hidden (obsolete)
Comment 54 Emily Lamancusa 2023-10-19 14:21:24 UTC Comment hidden (obsolete)
Comment 55 Emily Lamancusa 2023-10-19 14:21:29 UTC Comment hidden (obsolete)
Comment 56 Emily Lamancusa 2023-10-19 14:23:15 UTC
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>
Comment 57 Emily Lamancusa 2023-10-19 14:23:19 UTC
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>
Comment 58 Emily Lamancusa 2023-10-19 14:23:24 UTC
Created attachment 157459 [details] [review]
Bug 8838: Replace the atomic update boilerplate

Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Comment 59 Emily Lamancusa 2023-10-19 14:23:28 UTC
Created attachment 157460 [details] [review]
Bug 8838: (follow-up) Rebase, fix typos, and tidy.

Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Comment 60 Emily Lamancusa 2023-10-19 14:23:32 UTC
Created attachment 157461 [details] [review]
Bug 8838: Add SMS default/sample notices

Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Comment 61 Emily Lamancusa 2023-10-19 14:23:37 UTC
Created attachment 157462 [details] [review]
Bug 8838: (QA follow-up) one more typo fix

Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Comment 62 Emily Lamancusa 2023-10-19 14:26:55 UTC
Awesome, thanks! Everything looks good now :)
Comment 63 Tomás Cohen Arazi 2023-10-25 14:09:01 UTC
Pushed to master for 23.11.

Nice work everyone, thanks!
Comment 64 Fridolin Somers 2023-10-26 08:19:20 UTC
Enhancement not pushed to 23.05.x

Such a long report should have great release notes ;)
Comment 65 Katrin Fischer 2023-10-26 21:06:46 UTC
(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!