hold notification type not applying to all holds

[Diane Disbro]

We are experiencing random instances of hold notification type not printing on hold slips. This is the XUL client. On investigation, we find the hold notification defaults correctly set but the columns for Email Notify, Phone Notify, and Text Notify do not show these defaults for random items in the patron's holds list. Is this some kind of bleed-over from Webby which does not retain holds notification information?

[Terran McCanna (tmccanna)]

The only time we've seen this happen is when the patron unchecks notification boxes at the time of hold placement.

[Diane Disbro (ddisbro)]

I agree this is usually true but we have had quite a rash of this happening since December. Too much to be a coincidence? No one else has mentioned it so no one else is seeing the same behavior?

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Terran McCanna
Sent: Monday, January 29, 2018 11:21 AM
To: <email address hidden>
Subject: [Bug 1746043] Re: hold notification type not applying to all holds

The only time we've seen this happen is when the patron unchecks notification boxes at the time of hold placement.

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1746043

Title:
  hold notification type not applying to all holds

Status in Evergreen:
  New

Bug description:
  We are experiencing random instances of hold notification type not
  printing on hold slips. This is the XUL client. On investigation, we
  find the hold notification defaults correctly set but the columns for
  Email Notify, Phone Notify, and Text Notify do not show these defaults
  for random items in the patron's holds list. Is this some kind of
  bleed-over from Webby which does not retain holds notification
  information?

To manage notifications about this bug go to:
https://bugs.launchpad.net/evergreen/+bug/1746043/+subscriptions

[Pamela Smith (pamela-smith)]

We have had a rash of this happening also since our upgrade to 3.0. Prior to our upgrade this happened from time to time however, since our upgrade there have been too many to assume it's just patron's unchecking them by mistake.

Prior to the upgrade, when you entered the patron barcode to place the hold, it would default to e-mail if the patron had an e-mail address in their record (even if the default notification was not set). Now, in both the web & staff clients, the boxes are unchecked when you enter the patron's barcode; you have to manually check the notification method.

We would like to see this returned to the previous behavior where the default is e-mail if there is an e-mail address, text if that has been set as the default or phone if the e-mail & text fields are not populated.

[Andrea Neiman (aneiman)]

This might be related to / a duplicate of bug 1774268

[Andrea Neiman (aneiman)]

Actually disregard that, it seems that this is a XUL issue and the other one is webclient.

[Terran McCanna (tmccanna)]

Marking Won't Fix as this was a XUL-specific issue.