Code to require OPAC hold notification data causes minor breakage
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Invalid
|
Undecided
|
Unassigned |
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.
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.