Parts need to be more visible on the place holds screen

Bug #1422802 reported by Kathy Lussier
22
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Wishlist
Unassigned

Bug Description

Consider this my attempt at doing something that will improve the karma of parts in the #evergreen channel.

One issue we frequently find with parts is that users miss the parts selector on the Place Hold screen. If there are non-parted items on the bib record, the select menu defaults to the "All Parts" option, meaning that the resulting hold will be a title-level hold. However, quite often, the title may only have one or two non-parted copies, and there ends up being a long list of title-level holds while there are plenty of parted items that could fill the patron's request.

I'm working on code to increase the visibility of parts on the place holds screen. The code does the following:

* Adds some styling so that the "Select a part" is bold and there is some general padding around the parts selector.
* Adds a config.tt2 option to select a part with radio buttons instead of a select menu. The benefit to this option is that all the parts will immediately display on the place holds screen.

I'll post a work-in-progress working branch as soon as I get an LP number.

Revision history for this message
Kathy Lussier (klussier) wrote :

The work-in-progress branch is available at:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/lp1422802-more-visible-parts

I'm still working a couple of issues:

* A cleaner display for the parts when the radio button option is enabled.
* A better option to require users to select a part.

For the latter, our preference is to leave all the radio buttons deselected, forcing the user to make an explicit choice when selecting a part. I initially used the HTML5 required attribute to do so, but I now see that the attribute isn't supported in Safari at all and only has support in IE back to IE10 (not sure how far back we should support.)

The only other way I know of to require the field is to use javascript, but I know we want to limit the use of javascript in the public catalog. I'll keep digging, but I'm open to any suggestions.

Revision history for this message
Kathy Lussier (klussier) wrote :

I've updated the above branch to use javascript validation as a fallback for browsers that don't support the required attribute. When a browser does support the required attribute, the user will see the nicer, built-in browser alert instead of the javascript alert.

I still want to give it one last round of testing and add a Release Notes entry before adding a pullrequest tag.

Revision history for this message
Kathy Lussier (klussier) wrote :

Adding a pullrequest for the branch at working/user/lp1422802-more-visible-parts.

Test plan:

* Without changing any settings, place a hold on a title with parts (records 84 and 53 in the Concerto database).
* The standard dropdown menu parts selector should be easier to see, with a bold heading and some padding around the selector.

* In config.tt2, change the enable.parts.radio setting to 'true'
* Place a hold on a title with parts.
* The parts selection should now display radio buttons instead of a dropdown menu. The options should line up well, and resizing the screen should move parts options to the next line without separating the labels from the inputs.
* If you don't select a part, you should be unable to submit the form and receive a message telling you to select an option.
   - to test the backup javascript method of validation you need to a) use a browser like Safari that doesn't support the required HTML5 attribute or b) remove the required attributes from the input tags in parts/place_hold.tt2
* After selecting a part and placing a hold, ensure that the hold was placed on the correct part.

Changed in evergreen:
assignee: Kathy Lussier (klussier) → nobody
tags: added: pullrequest
Changed in evergreen:
milestone: none → 2.next
Kathy Lussier (klussier)
tags: added: needsreleasenote
Revision history for this message
Kathy Lussier (klussier) wrote :

Release notes entry added.

tags: removed: needsreleasenote
Revision history for this message
Ben Shum (bshum) wrote :

For note, both bibs 84 and 53 have items with parts, but their copy locations are unholdable in the concerto test data. I changed the "Magazine" copy location for bib 53 to holdable to perform the tests as described.

All looks well, pushed to master for good things to come for parts. Thanks Kathy!

Changed in evergreen:
status: New → Fix Committed
milestone: 2.next → 2.10-beta
Revision history for this message
Brent Mills (brent-5) wrote :

This was working well for us until we hit a roadblock with bibs that only had one part attached.

Example:

- in Chrome
- enable.parts.radio setting to 'true'
- Some Show - Season 3 (3 copies all with "Complete Set" as their part
- get to hold screen and click on the one, available radio button for "Complete Set"
- click "Place Hold"
- "Please Select Part" dialog continually comes up, not allowing hold to process

Was able to replicate this behavior in Safari/Chrome/Firefox. So I think it's affecting the HTML5/Javascript options equally?

Revision history for this message
Kathy Lussier (klussier) wrote :

Thanks Brent! I just replicated the bug. It appears to be the Javascript alert that's triggering, so I'll start there and see if I can get a fix in soon.

Revision history for this message
Dan Wells (dbw2) wrote :

I think document.forms doesn't do what you expect here for a single element (its just the input instead of a list). Maybe replace:

document.forms["PlaceHold"]["part"]

with:

document.getElementsByName("part")

instead?

Revision history for this message
Brent Mills (brent-5) wrote :

Dan,

I gave that a shot and we're back in business now. Successful parts holds on items with only one option for the part selection in radio button mode with the above change to js.tt2

Revision history for this message
Kathy Lussier (klussier) wrote :

Thanks Dan! Your suggested change does fix the problem Brent reported, but, unfortunately, the javascript alert no longer appears if the user does not select a part. I'll keep poking at it today.

Changed in evergreen:
status: Fix Committed → Triaged
Kathy Lussier (klussier)
Changed in evergreen:
status: Triaged → In Progress
assignee: nobody → Kathy Lussier (klussier)
Revision history for this message
Kathy Lussier (klussier) wrote :

Dan pointed out that the problem was a missing parenthesis on my part. Once I fixed that, Dan's fix seemed to do the trick. I've rolled it into a branch that's in the working repo at:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/lp1422802-visible-parts-fix

Revision history for this message
Ben Shum (bshum) wrote :

Picked the fix to master to complete this work.

Changed in evergreen:
status: In Progress → Fix Committed
assignee: Kathy Lussier (klussier) → nobody
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.