Backup javascript validation for parts on place holds form was removed

[Kathy Lussier]

Evergreen version: All supported

Prior to the work on bug 1098685, there was some javascript validation used on the place hold form to ensure users selected a part if they were using a browser that did not support the HTML5 required attribute. The required attribute was particularly important for Evergreen sites that had enabled radio parts because the interface does not select a part by default as is done with the dropdown menu.

In this commit:
http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2621af6377970470e347559d67f0da5de47aaa9f

we moved the place hold form validation to a new file - holds-validation.js. The file validates that the user enters contact information when applicable, but does not include the previous check we had for monographic parts. Therefore, if a user tries placing a hold on a record with parts using an older browser, but neglects to select a part, the hold will fail without appropriate feedback.

To replicate this issue:
- In config.tt2, set enable.radio.parts to true.
- On lines 129 and and 132 of place_holds.tt2, remove the 'required' attribute from the input tags. Since most of us are probably using a browser that supports the required attribute, this step allows you to replicate the experience of a user who is not using such a browser.
- Click Place hold on a record with parts. If using Concerto data, you can use record 84, but you will first need to set the 'Theses' copy location to holdable since no parts in the Concerto dataset are holdable by default. If this step annoys you, there is a pullrequest at bug 1672435 that will address this problem.
- On the Place hold screen, skip the parts selection, but fill out all other required fields.

When you hit submit, you'll get to the hold confirmation page with neither a success nor failure message. The hold will not successfully place.

I'm also noting that all modern browsers appear to support the required attribute now. This functionality is still needed, though, as a failsafe for those users who have older browsers.

[Jessica Woolford (jwoolford)]

Perhaps this goes without saying, but this bug affects those of us still using the xul staff client in 2.12 as well.