Hold request update notification preferences on change

Bug #1570072 reported by Josh Stompro on 2016-04-13
This bug affects 9 people
Affects Status Importance Assigned to Milestone

Bug Description


I would like to see an optional behavior that always updates the notification preferences set in unfulfilled holds when the users hold notification preferences are updated by staff or by the user.

This would solve the problem of needing to manually change the notification settings for all outstanding holds when a customers phone number changes, or they add an email address and want email hold notifications, or they add/change their sms number and carrier and want sms hold notifications, etc.

This should work for both catalog "my account" based changes along with staff client based changes.

There could be some limits to protect the one off hold notifications. For example, if a user has a default phone number set, but enters a different number for one hold, and then their default notification preferences get changed, update only the holds that had the old default phone number to the new default phone number and leave the others alone.


Terran McCanna (tmccanna) wrote :

I like this, but in order to accommodate the people who may not want all their previous unfilled holds updated, what if it prompted "Do you wish to update the notification settings on all of your outstanding holds?"


Kathy Lussier (klussier) wrote :

Adding links to some IRC discussion on this topic that happened after the bug was filed:



Kathy Lussier (klussier) on 2016-05-20
Changed in evergreen:
status: New → Triaged
importance: Undecided → Wishlist
Kathy Lussier (klussier) wrote :

Linking to another IRC log on this topic.

MassLNC is currently writing up requirements for this project. I'll share them here when they are ready.

Kathy Lussier (klussier) wrote :

Huh. I apparently intended to link to an IRC log on this topic, but I have no idea now how I would go about finding that log. I also forgot my promise to post our development requirements here when they were ready. They can be found at http://masslnc.org/node/3388

Terran McCanna (tmccanna) wrote :

MassLNC has contracted with Equinox to develop this functionality. Specs are here:


And original requirements here:


Elaine Hardy (ehardy) on 2019-03-06
tags: added: holds
Galen Charlton (gmc) wrote :

A branch for review is available at working/collab/gmcharlt/lp1570072_update_hold_notifications / https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/gmcharlt/lp1570072_update_hold_notifications

tags: added: pullrequest
Changed in evergreen:
milestone: none → 3.4-beta1
status: Triaged → Confirmed
Galen Charlton (gmc) on 2019-09-11
Changed in evergreen:
milestone: 3.4-beta1 → 3.next
Terran McCanna (tmccanna) wrote :

PINES has had this in production for a few weeks and hasn't seen any issues so far, but I'm waiting to sign off until the rest of the ECDI has a chance to chime in.

Changed in evergreen:
milestone: 3.next → 3.5-alpha
Andrea Neiman (aneiman) wrote :

Noting that ECDI gave an approval to this project in September 2019 after testing on stock Concerto as part of Equinox's dev project for this feature.

If it's working for PINES or anyone else we would appreciate a Launchpad signoff.

Terran McCanna (tmccanna) wrote :

I've checked with the rest of the ECDI group and they're okay with me giving the signoff:


tags: added: signedoff
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers