Webstaff: Required attribute on actor.stat_cat only honored when free text is true

[Jason Boyer]

Eg 2.12

While looking at bug 1618949 I set a couple stat cats to be required to see how things worked. One allowed free text entry and the other didn't, and only the one that does allow free text entry is actually verified when considering required fields. (Both display when you only show required fields, but it doesn't actually require you to select anything.)

To verify: create a new actor stat cat, then make it required and turn off free text. Add at least one value to the list for it and load a patron record. Show / hide some fields and notice that its always displayed, but you can save the record at any time without making a selection.

[Andrea Neiman (aneiman)]

Confirmed 2.12.1

[Cesar V (cesardv)]

I've pushed a fix for this to the following branch:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/cesardv/lp1695062_WebStaff_Patronreg_Required_StatCats

I am not a huge fan of the custom button-ui with an attached ul dropdown that the non-freetext stat cats are using, but went ahead and fixed the issue with it. If I get some time, I might push another a branch with a refactor that makes it use a regular select, like some of the other dropdown menus are using.

[Josh Stompro (u-launchpad-stompro-org)]

Signoff Branch - http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/stompro/lp1695062_WebStaff_Patronreg_Required_StatCats_signoff

I can confirm that when I follows the test plan above, I was prevented from saving the record when the stat cat wasn't filled in.

I think there is definitely a usability issue with the stat cat drop downs menus in the web client, when the last stat cat on the page requires selecting from the list, it is hard to select the options because they show up below the end of the page. Does anyone else see that?

Josh

[Kathy Lussier (klussier)]

Thanks Cesar and Josh! Merged to master and release 2.12.

I agree with you, Josh, on the usability issues. I mention a similar issue here - https://bugs.launchpad.net/evergreen/+bug/1464767/comments/9 - but that bug has been marked invalid (it started as something else) and this issue probably warrants its own bug.

Even when there isn't a menu reaching the bottom of the page, I often feel like the web client interfaces could do with some padding at the bottom of the page.

[Jason Boyer (jboyer)]

In reference to comment 4 I added 2 inches of padding to the bottom of src/templates/staff/base.tt2 here because using the report editor without an space at the bottom was maddening. Since it seemed a cosmetic thing for the most part I didn't think to bug or branch it. Given the number of custom dropdown stuff we use it may not be optional. (Native UI dropdowns can drop up instead if they need and have various other benefits over a custom control that's kept to the pages internal boundaries.)