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

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

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.

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

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

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.

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.

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

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

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

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.

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

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.

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.

Alright, James added his signoff on GitHub, and I've added mine here:

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

For the record, here is James's signoff commit:

https://github.com/jamesrf/Evergreen/commit/ad3675fa66d985c84d300b2afb3477ef9e134dc0

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!