web client reporter: can't hard code a list of filter values

[Chris Sharp]

When creating a reports template, it is often useful to enter ("hard code") values into a filter. Current example is a report on the Atlanta Zoo DVD/Pass that is available for Georgia libraries. As there are two editions of the DVD that are valid, we would prefer to enter both bib IDs into a filter so those running the reports don't have to look them up.

In the web client reporter UI, if you create a filter and change the operator to "In list", then click "Change Filter Value", you're presented with a "Value:" modal where you can enter your values. However, if you enter a comma-separated list (e.g., "5487517,5628015"), the resulting SQL uses that literal value ("5487517,5628015") rather than the desired list of each value separately.

Evergreen 3.0-ish through master
OpenSRF 3.0.1
Ubuntu 16.04 LTS
All browsers

[Anna Goben (agoben)]

Ooo, yes. This is another thing about the wc reporter that is really, really frustrating!!! I've tried every workaround I could come up with for added punctuation to force the entries to be distinct, but no luck.

[Beth Willis (willis-a)]

confirmed

EG 3.0.9
Browser: Chrome
OpenSRF 3.0.1

[Terran McCanna (tmccanna)]

Bumping this up to "High" - we're still having to go into the XUL client to create these reports.

EG 3.0

[Anna Goben (agoben)]

Ran into this yet again today. This makes a lot of reporting impossible to cleanly configure.

Evergreen 3.2

[Remington Steed (rjs7)]

Here's a branch that fixes this the same general way the XUL code did (with a few small changes):

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

From the commit message:

    This commit borrows directly from the XUL reporter code (see
    function __default_value_event_handler () in
    Open-ILS/web/reports/xul/template-config.js). Basically, when the filter
    value is saved, certain cases need special treatment, such as splitting
    an "in list" value on commas. This commit includes a helper function
    which does the special treatment and saves the filter value. This helper
    is called both when the value itself is changed, and when the operator
    is changed.

[Galen Charlton (gmc)]

I've tested and pushed the patch + a followup to

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

The follow-up just moves the function for munging filter values to the template service.

[Dan Wells (dbw2)]

This had some merge conflicts, and I was a little on the fence whether the fixes were trivial or not. So, here is a rebased branch, but I might decide to go ahead and push it in after sleeping on it:

working/user/dbwells/lp1785061_signoff_rebase

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

Thanks, all!

[Dan Wells (dbw2)]

After 82 days of sleeping on it, I feel confident enough. Pushed to master through rel_3_1. Thanks again, all!