Code to require OPAC hold notification data causes minor breakage

Bug #1710404 reported by Jason Stephenson on 2017-08-12
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

Evergreen version: Master
OpenSRF version: Master
PostgreSQL version: 9.5

It looks like the code for bug 1098685 may not work exactly as expected with default options. I'm testing some holds-related changes to the back end and here's what I see:

The following is happening in Firefox 54 and Chromium Version 60.0.3112.78 (Developer Build) in the web staff client. (I have not tested the OPAC, but I imagine the same happens there.)

When placing a hold for a patron in the web staff client, the "Yes, by phone" notification checkbox is automatically checked and the phone number field is empty. The first time I click submit, nothing at all happens. The second time I click submit, I get the dialog asking me to fill in missing information and the phone number box is highlighted in yellow. If I fill that data in or uncheck the notification button, the hold will now go through.

If I uncheck the phone notification checkbox before clicking submit, the window flashes as if reloading and the checkbox remains checked. If I uncheck it a second time, it remains unchecked. Clicking Submit this time, places the hold as expected.

The feature that I am testing is a new org. unit setting to allow a certain number of duplicate holds to be placed for a patron. If I click the "Place another hold for this title" link on the results page, I am taken back to the place hold screen. The phone notification checkbox is checked, the submit button is grayed out. Unchecking the checkbox or adding a phone number to the box do not change the state of the submit button. I am unable to click it.

(Ultimately, my development will render that link obsolete, but it is useful for testing this part of the development.)

I don't think this behavior is as intended, and I've seen the clicking twice required to kick off an onclick or onsubmit JS handler before. It happened while I was working on bug 1189989 because the script was checking for some condition that wouldn't be possible to know until after the script ran once, or something like that.

Revision history for this message
Jason Stephenson (jstephenson) wrote :

Just to add for clarification, the above was seen with my branch, rebased on master at about 17:00 UTC on 2017-08-12 with a fresh installation of the concerto db and the pgtap extension added.

Revision history for this message
Jason Stephenson (jstephenson) wrote :

I just checked the OPAC in both of the above browsers.

The described behavior DOES NOT occur there. It appears to be webstaff only.

I have not build a xul client to test there, but perhaps I should.

tags: removed: opac
Revision history for this message
Jason Stephenson (jstephenson) wrote :

I just checked with the XUL client.

The "Place another hold for this title" behavior from the description happens in the XUL client.

The other behavior does not, though unchecking the phone notification checkbox before clicking submit does appear to cause a page refresh. At least, the Submit button appears to flash as if the page were redrawn.

Revision history for this message
Andrea Neiman (aneiman) wrote :

3.0 beta

I tested this behavior in the web client & OPAC for both Chrome (60, 64 bit) and Firefox (54, 32 bit) as well as in the XUL client.

In all cases, the following happened:

If I click submit with the phone number box checked & field blank, I get a popup asking me to fill out all required fields & the field highlighting changes to yellow.

If I uncheck the phone notification I am able to click submit and the hold is successfully placed.

I'm not seeing any differences in behavior if I come from "place another hold for this title" -- it's working as expected there too.

Revision history for this message
Jason Stephenson (jstephenson) wrote :

I noticed the behavior changed after the fix for bug 1710512 went in. I'm not sure what that did to fix it, but I've not seen my reported behavior since. I'll set this bug invalid.

Changed in evergreen:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers