OU selectors in web client do not provide scrollbars and are ordered incorrectly

Found an example of scrollable Bootstrap dropdowns here:

http://stackoverflow.com/questions/19227496/scrollable-menu-with-bootstrap-3-menu-expanding-its-container-when-it-should-n

Do we want all dropdowns to be scrollable? I'm guessing we should only apply the scroll CSS for non-mobile screens, since the default view is probably more mobile-friendly (needs confirmation).

Sorry! As Bill pointed out in IRC, the staff client selectors do not honor the custom org tree. Those are only used in the catalog. So we just need to make sure they sort by whatever the current default sort order is.

Pushed two commits to the tip of the patron editor branch (since I'm working in there now). Commits are tagged with LP#1464767. I can move them to a separate branch if we want to merge them by themselves.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1452950-web-client-patron-reg-phase1

Commits include a change to sort org selectors by shortname (by default) and adding scroll bar to org selectors greater than 200px vertical.

I'd like to merge this sooner rather than later. Are the two LP#1464767 commits (not including the mislabeled "Patron edit billing => physical") in the user/berick/lp1452950-web-client-patron-reg branch still the right ones?

Our testers have suggested making the dropdown menus here and in places like the Actions menus large enough to limit scrolling whenever possible. Makes things easier when scrolling is kept to a minimum.

Galen, yes, those are the commits.

Elaine, I agree we don't want it to be too aggressive. The height at which the scroll bars appear is controlled by templated CSS, though. So modifying the value locally if necessary would be the same as other template (tpac, browser client, etc.) CSS changes.

I've paritally addressed the org sorting issue (I've not touched custom trees), but it may need to be revisited. Because of the way the org unit list is currently retrieved by the web client, it can only be sorted one way. That's fine so long as the way I've sorted it (shortname) is what you're displaying to the user, but if we need to be able to sort by name or anything else the sort method will either need to be made a request time option (I'm not sure how best to do that) or there may need to be multiple "classes" for aou, one for each required sorting. I'll also understand entirely if the result is that I've not done things the Angular way and this isn't where/how it should be done.

Here's the (one-liner, woo) branch: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jboyer/lp1464767_sort_aou

Following up on Elaine's comment, looking at the menus on webby (I've lost track of what has made it into master), there is still a bit of awkwardness that occurs when the menu length exceeds the length of the page. I've mostly seen this happen on compact pages (e.g. Holdings View of a record when there are no copies attached). A larger font size is more likely to make the menu exceed the page length, and I've noticed that it is more likely to occur in Firefox.

Basically, you need to do a dance between the page scrollbar and the menu scrollbar in order to reach the menu items appearing at the bottom of the list. The screencast below illustrates the problem:

https://drive.google.com/file/d/0B74gDMUDwDXqTmhRYzc4b04wZDg/view

The original bug was addressed with the code berick refers to in comment #4. The other issues mentioned after the code was merged still exist, but are really separate issues from what was reported in the original bug. They really belong on a new bug.

Michele Morgan just happened to file a bug today that fits the bill. bug 1669120

Setting this as Invalid for lack of a better status that means "merged through a big web client merge that has no associated LP number that can be used to set a duplicate."