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

Bug #1785061 reported by Chris Sharp on 2018-08-02
56
This bug affects 12 people
Affects Status Importance Assigned to Milestone
Evergreen
High
Unassigned
3.1
High
Unassigned
3.2
High
Unassigned
3.3
High
Unassigned

Bug Description

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) wrote :

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.

Remington Steed (rjs7) on 2018-08-02
Changed in evergreen:
status: New → Confirmed
Beth Willis (willis-a) wrote :

confirmed

EG 3.0.9
Browser: Chrome
OpenSRF 3.0.1

Terran McCanna (tmccanna) wrote :

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

EG 3.0

Changed in evergreen:
importance: Undecided → High
Anna Goben (agoben) wrote :

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

Evergreen 3.2

Remington Steed (rjs7) on 2019-05-02
Changed in evergreen:
assignee: nobody → Remington Steed (rjs7)
Remington Steed (rjs7) wrote :

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.

Changed in evergreen:
assignee: Remington Steed (rjs7) → nobody
tags: added: pullrequest
Changed in evergreen:
milestone: none → 3.4-beta1
Galen Charlton (gmc) on 2019-05-13
Changed in evergreen:
assignee: nobody → Galen Charlton (gmc)
Galen Charlton (gmc) wrote :

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.

tags: added: signedoff
Changed in evergreen:
assignee: Galen Charlton (gmc) → nobody
Galen Charlton (gmc) on 2019-05-22
Changed in evergreen:
milestone: 3.4-beta1 → 3.3.2
no longer affects: evergreen/3.3
Dan Wells (dbw2) on 2019-05-24
Changed in evergreen:
assignee: nobody → Dan Wells (dbw2)
Dan Wells (dbw2) wrote :

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!

Changed in evergreen:
assignee: Dan Wells (dbw2) → nobody
Changed in evergreen:
milestone: 3.3.2 → 3.3.3
Remington Steed (rjs7) on 2019-08-13
Changed in evergreen:
milestone: 3.3.3 → 3.4-beta1
Dan Wells (dbw2) on 2019-08-14
Changed in evergreen:
assignee: nobody → Dan Wells (dbw2)
Dan Wells (dbw2) wrote :

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

Changed in evergreen:
status: Confirmed → Fix Committed
assignee: Dan Wells (dbw2) → nobody
Galen Charlton (gmc) on 2019-09-11
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers