Web Staff Client - Problems cloning existing reports

Bug #1642344 reported by Terran McCanna on 2016-11-16
54
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Evergreen
Medium
Unassigned
3.0
Medium
Unassigned
3.2
Medium
Unassigned

Bug Description

There are several cloning issues in the 2.11 web client that occur when cloning a template that was originally created in the xul interface:

1) It doesn't open in the standard template editing interface, which is confusing (see screenshot comparing the two)

2) The "Enable nullability selection" checkbox is missing

3) If you had a Boolean value set as a filter in the original template (such as Deleted Equals False), the value doesn't carry over or allow you to set it

4) It doesn't allow you to add additional fields, or even display the other fields that are available

If any of this was intentional due to major changes on the back end, then it would be helpful to users if there were an on-screen message to inform them that they will have to re-create those templates from scratch in the new interface.

Terran McCanna (tmccanna) wrote :
Kathy Lussier (klussier) wrote :

I agree with Terran on the above issues. Initially, I was thinking we should break these issues out into separate bugs, but everything boils down to issue #1. If we were using the standard template creation interface to clone templates, we would have all of the items reported in 2, 3 and 4.

We are losing a bit of functionality by cloning reports this way.

Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
Kathy Lussier (klussier) wrote :

I missed Terran's original comment that this happens with templates created in the XUL client. I see now that the ones created in the web client do indeed get cloned in the standard template editing interface.

Is there some kind of constraint that prevents us from viewing XUL-era templates in the new template editing interface?

Changed in evergreen:
milestone: none → 3.0-alpha
Changed in evergreen:
milestone: 3.0-beta → 3.0-beta2
Changed in evergreen:
milestone: 3.0-beta2 → 3.0-rc
Galen Charlton (gmc) on 2017-09-27
Changed in evergreen:
milestone: 3.0-rc → 3.0.1
Changed in evergreen:
milestone: 3.0.1 → 3.0.2
Changed in evergreen:
milestone: 3.0.2 → 3.0.3
Changed in evergreen:
milestone: 3.0.3 → 3.0.4
Changed in evergreen:
milestone: 3.0.4 → 3.0.5
Changed in evergreen:
milestone: 3.0.5 → 3.0.6
Terran McCanna (tmccanna) wrote :

MassLNC has contracted with Equinox to fix this bug (funding contributed by PINES, Sitka, PaILS, Evergreen Indiana, and SC LENDS). Tech Specs are available at:
https://yeti.esilibrary.com/dev/public/techspecs/clone_reports.pdf

Changed in evergreen:
milestone: 3.0.6 → 3.0.7
Changed in evergreen:
milestone: 3.0.7 → 3.0.8
Changed in evergreen:
milestone: 3.0.8 → 3.1.3
Kathy Lussier (klussier) wrote :

Just adding a note that, as reported in IRC today, this feature has become even less functional than originally reported in this bug. frank_g and jihpringle both reported that, in 3.1., after selecting a folder for the cloned report, the user is taken to a screen that just says "Loading".

Changed in evergreen:
milestone: 3.1.3 → 3.1.4
Deborah Luchenbill (deborah) wrote :

I can confirm Kathy's most recent comment is also happening in 3.0.9.

Andrea Neiman (aneiman) wrote :

This development is in partner testing and we will be submitting a community branch shortly.

Changed in evergreen:
milestone: 3.1.4 → 3.1.5
Galen Charlton (gmc) wrote :

A patch is available at the tip of the user/gmcharlt/lp1642344_xul_report_cloning branch:

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

tags: added: pullrequest
Terran McCanna (tmccanna) wrote :

We've applied this to a test server with PINES data and tested. Everything we tested worked great!

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

tags: added: signedoff
Kathy Lussier (klussier) on 2018-08-27
Changed in evergreen:
assignee: nobody → Kathy Lussier (klussier)
Kathy Lussier (klussier) on 2018-08-27
Changed in evergreen:
assignee: Kathy Lussier (klussier) → nobody
Kathy Lussier (klussier) wrote :

While giving this branch one last round of testing before merging, I encountered an issue I hadn't seen in my previous testing. I tested cloning a xul-era money report that included a filter with an "In List" operator and the following for the filter value - [forgive_payment,credit_payment,goods_payment,work_payment]

If I create a report in the web client directly from this xul-era template, the report works fine. Those values are listed in the filter section, and there is no way to add to or edit them, which is expected behavior.

If I clone the template, this filter appear as if they carried over correctly to the webstaff template. However, if I then run a report off of the new template, the user is expected to enter the values in this filter.

I've attached a screenshot.

Everything else works great! Thanks Galen!

Changed in evergreen:
milestone: 3.1.5 → 3.1.6
Chris Sharp (chrissharp123) wrote :

I may be wrong, but I think the "In list" filter issue is related to bug 1785061, where you can't pre-enter ("hard-code") values for the list within the template definition.

Mike Rylander (mrylander) wrote :

Chris, I think you're write. My preference is to push this branch now, because cloning reports is very important, and address the template-level in-list issue separately.

Mike Rylander (mrylander) wrote :

Picked and pushed to 3.0-master. Thanks, Galen, Terran, Chris, and Kathy!

Changed in evergreen:
status: Confirmed → Fix Committed
tji@sitka.bclibraries.ca (tji) wrote :

We deployed the fix and started to see issues.

Cloning process seems fine. Without updating anything the template can be saved.

When running reports from the cloned templates, there were errors complaining either lacking field in Group By or missing From clause.

When cloning the templates, removing then putting back the complained fields solved the issue.

It seems the issue is related to how the tables are joined. See the screenshot. Nearly all our templates starting from Item table leading to Call Number > Bib > Simple Record Exact are affected.

From Item table to Shelving Location or Copy Status tables sometimes have the issue, too.

Below is a sample error, which seems different. It complains of circ_lib in circulation table, which is used as a filter. The template simply counts circs based on the checkout library filtering on circ_lib (circ table), checkout time and checkout staff profile (we has special profile for selfcheck).

: DBD::Pg::st execute failed: ERROR: column "f45381a54504218e39aca33492d29306.circ_lib" must appear in the GROUP BY clause or be used in an aggregate function LINE 8: HAVING "f45381a54504218e39aca33492d29306"."circ_lib" IN ($... ^ at /srv/openils/bin/clark-kent.pl line 255.

Running the report from these XUL templates has no issue.

Andrea Neiman (aneiman) wrote :

Hi Tina, please file a follow up bug for this. It would be helpful if the new bug report includes the full JSON from the original pre-clone template.

Changed in evergreen:
status: Fix Committed → Fix Released
tji@sitka.bclibraries.ca (tji) wrote :

Attached is an example template before being cloned, cloned without editing and cloned with replaced fields from linked tables. When editing, I simply removed all the fields not directly from the source table, then followed the same path to put them back. Nullablity is not used on UI.

tji@sitka.bclibraries.ca (tji) wrote :

Another example. Running reports from the cloned without editing template works, but the result is not accurate.

Remington Steed (rjs7) wrote :

For the record, Tina did open a new bug (bug 1796945) for the issues mentioned in #14.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers