Angular admin pages need filters

I've pushed a WIP patch to collab/gmcharlt/lp1846042_admin_page_filters to enable grid column filtering for most Angular admin pages. This isn't a complete patch, but should be enough for useful initial testing.

From initial testing of Galen's branch, filters appear on basic admin pages (including hold policies, booking resources, and the various server admin pages) and work correctly.

Some pages have both an org unit filter and a filterable org unit column. The filters work just fine together, but having both is arguably redundant and confusing.

With a visible filter on every column, admin pages can get very cluttered. Maybe there could be a small button next to each column name to show/hide the filter for that column? The button could change color when a filter has been applied on that column.

With a large number of columns, the filters quickly become misaligned with the columns, so that you can't tell which filter applies to which column (see Local Admin > Hold Policies for a good example). Perhaps columns should expand to accommodate the width of the filter when the filter is visible?

TODO: Confirm whether the issues reported here are resolved by the fix for bug 1855931, combined with Galen's WIP branch above.

Working branch user/jeffdavis/lp1846042-admin-page-filters rebases Galen's commit to current-ish master. It works as well as before, but the issues I identified earlier remain unresolved. In particular, I was hoping that the commit for bug 1855931 (which is now in master) would fix column alignments for filters, but no such luck -- on Local Admin > Hold Policies, the filters are still so unaligned that you can't realistically use them on that page. We could commit the current fix and open a separate bug to address column alignments, I suppose.

Said this in IRC just now (http://irc.evergreen-ils.org/evergreen/2020-04-29#i_443901), but I'm leaning towards thinking this should wait to be implemented until the filters aren't so cluttering and misaligning. Agreeing with Jeff, if you can 1) hide the filters by default and 2) alter the column displays so they are aligned with the filters, when present, that would help. I'm not willing to push this as-is, though without others' input.

Working branch user/gmcharlt/lp1846042_take2 now has the current WIP. Happily, ng-bootstrap 4.1.0 and later add the container="body" option to ngbDropdown, allowing the filter controls to now stay aligned with the rest of the columns while letting the user see the entire filter button.

Emphasis is on WIP; the branch as it stands breaks the use of gridFilter to establish filtered links for interfaces like the Z39.50 attributes.

With more filtered Angular grids getting getting added, I see improving the filter UI as increasingly important.

I propose the filter dropdown toggle be the only visible element when the dropdown is collapsed (and that it be changed to text) and that the filter value input be moved into the drodown menu.

I realize this diminishes some of the value of the filter UI, because you see less information at a glance. But it solves all of the spacing issues and, as it stands, some of the grid filters are so packed, their contents are not visible anyway.

Three images (clumsily combined into one for LP) demoing what I propose.

I agree that the filter UI definitely needs improvement. For your suggestions, Bill:

1. Filter toggle only visible element when collapsed -- yes. Totally agree.

2. That it should change to text -- I'm okay with this, but I'd probably be just as happy if the toggle just changed color to indicate that something's being filtered as Jeff suggested upthread. If you do want to pursue having it change to text, could we still have the color change? I think that's really helpful as just a quick visual indicator.

3. Filter value input in dropdown menu -- Does this just mean that it won't display beneath the filter, e.g. "Operator: Is Not" in text? I'm okay with that. I think it clutters up the UI, although I understand the urge to have more information be visible.

So I guess after saying all that, I'm in favor of your suggestions. Refreshing my memory on current master right now with Angular Acq Search, it looks like we do have the color change when a filter is being used so I wouldn't want to lose that behavior.

Thanks, Tiffany.

1. Cool

2. It can certainly change color. I just wanted to make sure a non-color option was included for accessibility. No reason it can't also change color.

3. That's right. The details of the filtering all live within the drop-down which is only visible when clicking on the filter drop-down link/button.

I'll bake these into a branch so we can further review, test, etc.

Here's an unsquashed, undocumented branch in progress with the proposed filter changes.

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1846042-grid-filters-streamline

It includes a minor date filter fix that to avoid JS errors when using the 'between' filter.

I have deployed my branch at https://evgdemo.kcls.org/eg/staff (admin / demo123)

Once logged in, the new ACQ General Search is a good place to see the various filters.

I like this! If someone else wants to take a look behind me just in case, I'm happy to sign off on it.

I agree with Tiffany. This is good. AFAIC, Tiffany proceed with the sign off.

Sounds good to me!

I have tested this code and consent to signing off on it with my name, Tiffany Little, and my email address, <email address hidden>.

Thanks, all. I'll push a rebased/squashed branch with sign-offs.

Cleaned up branch with sign offs.

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1846042-grid-filters-streamline-2

And now... I'll push another branch that includes the original code to enable filters.

Here's a new branch with the admin filters enabled and the grid filters reorganized:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1846042-grid-filters-streamline-3

This includes sign-off for Galen's commits (one had only his) and a few miscellaneous repairs.

The main changes with this commit is:

Add an explicit Close button to filter dropdowns to cover cases where the user wishes to close the dropdown without making any changes and clicking-away is not supported (and they don't know clicking on 'Filter' will also close it).

Some dropdowns required [autoClose]="false" because they would close prematurely while modifying the filters. For example, setting a date values opens another date-select dropdown, which the filter dropdown sees as 'clicking away', so it closes.

Note that any other action (Apply, Clear, input value change) will also close the drop-down.

Commit includes a few other minor repairs and display improvements.

I've tested this patch with production data and the functionality is looking great!

I'm prepared to add my signoff, but have come across a few issues that would be great to get resolved if they're easy fixes.

- Text filters (Contains, Starts with, Ends with, etc.) are case sensitive, which could cause confusion. Case INsensitive filters would be much more useful

- Columns with Yes/No values have filter options of True/False/Any. Filter options should match the column values.

- Interval data types aren't filterable. Instead of the filter button, 'I don't know how to filter <column name>' appears. Examples: Circulation Duration Rules, Circulation Recurring Fine Rules.

Since this fix provides much needed missing functionality, I am willing to signoff and open new bugs for the above issues, but might some of these be quick to fix?

One more issue:

- Columns that are links should not have a filter button. Examples: Hard due date changes, Z39.50 servers

My signoff is here:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mmorgan/lp1846042_admin_filters_signoff

Should this get pushed, I'll open bugs for the remaining issues.

Thanks Bill!

Thanks, Michele. I'll do one last run through then merge...

Merged to 3.6 and master. Thanks All!

The commits did not cleanly cherry pick into rel_3_5, so I have not addressed 3.5 with my merge.