web client: reports - column labels spontaneously re-sort when deleting template fields

Bug #1751800 reported by Felicia Beaudry on 2018-02-26
82
This bug affects 16 people
Affects Status Importance Assigned to Milestone
Evergreen
Medium
Unassigned
3.1
Medium
Unassigned
3.2
Medium
Unassigned
3.3
Medium
Unassigned

Bug Description

When creating templates in the reports module of the web client (3.0.3), the column labels column spontaneously re-sorts in reverse order upon deleting a field. Deleting a second field causes the column labels to re-sort again to the original order. I was able to duplicate this in more than one template, and I've had a couple of other people able to recreate it as well. Screenshot provided.

summary: - web client reports module column labels spontaneously re-sort when
- deleting template fields
+ web client: reports - column labels spontaneously re-sort when deleting
+ template fields
Terran McCanna (tmccanna) wrote :

Yes, this is happening to me as well. It appears to be resorting into the order they were originally in.

Changed in evergreen:
status: New → Confirmed
Jane Sandberg (sandbej) on 2018-03-23
tags: removed: reporttemplates
Changed in evergreen:
importance: Undecided → Medium
Anna Goben (agoben) wrote :

This is highly annoying, especially since it takes so many more clicks already to set up the order in which columns appear now than it did in the XUL client.

Tiffany Little (tslittle) wrote :

+1 to Anna's comment. It's very frustrating.

Jennifer Pringle (jpringle-u) wrote :

Also +1 to Anna's comment. It's very time consuming to re-sort.

Stareagle (sforrest) wrote :

This happens for me both in the Display Fields and the Filters tabs. Sorting the filed order is one thing I definitely miss from the XUL client, much easier.

Stareagle (sforrest) wrote :

The other thing I have found out which is perhaps not related.

I add a field say 'Created Date' of transform 'Date'. If I now add a different field say 'First Name' without actually selecting a new transform it will default to the last one used, ie, 'Date' instead of 'Raw Data' which is what i would expect.

Tiffany Little (tslittle) wrote :

Hi Stuart,

I opened a new bug for your issue, since I think it's a different thing.

https://bugs.launchpad.net/evergreen/+bug/1810965

John Amundson (jamundson) wrote :

Tiffany, and Stareagle, I believe this behavior was reported here: https://bugs.launchpad.net/evergreen/+bug/1778521

Tiffany Little (tslittle) wrote :

Thanks John! That's what I get for not searching well enough! :)

Remington Steed (rjs7) wrote :

I thought the reverse-sorting bug occurred in this file:

staff/reporter/services/template.js

In this function:

service.removeField = function (type, field)

But according to console.log(), the order of the array (and their "index" properties) is the same at the beginning of the function as at the end, and that already appears to be the reversed order. So it seems that something else is reversing the order before removeField() is called.

James Fournie (jfournie) wrote :

Hi! I think Remington you were wrong. I did a test and found that the fields are getting reversed in service.removeField() -- likely due to the pop() which pops the last element, these elements are push()ed onto a fresh array with the reversed order. I've pushed a patch here on Github.

https://github.com/jamesrf/Evergreen/commit/656410f3c8a4e243fc802934a3df75220ca3af28

<email address hidden>:jamesrf/Evergreen.git branch LP1751800

Remington Steed (rjs7) wrote :

James, if I was wrong, that's great! Because I couldn't think of anything else that could be causing the problem. A quick test shows me that it works. Are you able to create a branch in the Evergreen working repository? (https://git.evergreen-ils.org/?p=working/Evergreen.git) If not, I'll grab your commit from GitHub.

tags: added: pullrequest
Jason Stephenson (jstephenson) wrote :

James's commit on github appears to lack a Signed-off-by: in the commit message. We need that as an assurance that he is actually able to share the code with Evergreen proper. It's a formality, but it helps us track things is there ever is a dispute about the code.

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

Glad to have this brought to my attention, since even one word code changes deserve three sign-offs, sometimes :) Pushed to master through rel_3_1. Thanks, James and Remington!

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