Backup javascript validation for parts on place holds form was removed
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Confirmed
|
Medium
|
Unassigned |
Bug Description
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://
we moved the place hold form validation to a new file - holds-validatio
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.
description: | updated |
Changed in evergreen: | |
status: | New → Confirmed |
tags: |
added: circ-holds removed: holds |
tags: |
added: cat-parts removed: parts |
Perhaps this goes without saying, but this bug affects those of us still using the xul staff client in 2.12 as well.