Web Client: Sort Priority not honored in egGrid

Bug #1790169 reported by Erica Rohlfs
66
This bug affects 13 people
Affects Status Importance Assigned to Milestone
Evergreen
Medium
Unassigned
3.1
Medium
Unassigned
3.2
Medium
Unassigned
3.3
Medium
Unassigned

Bug Description

Web Client version 3.0.9

When configuring columns in the Check In screen or the Capture Holds screen, the user can set a Sort priority. Once the user navigates away from the screen, the sort priority is no longer honored, and the user must reset the column priority.

To recreate, go into either the Check In screen or Capture Hold screen. Select the column picker drop-down option Configure Columns -> set a Sort priority on one of the columns -> go back into the column picker drop-down and select Save Columns. Navigate away from the screen (or simply refresh the screen), go back into the column configuration option and notice that the sort priority is no longer set.

Andrea Neiman (aneiman)
tags: added: sorting
tags: removed: sorting
tags: added: sorting
Revision history for this message
Andrea Neiman (aneiman) wrote :

I tested this extensively in 3.1.5 with spot checks in 3.1.4 and 3.0.9.

1) Pick a grid, any grid -- I looked at all of Circ & Cataloging in 3.1.5
2) Set a sort priority for various columns in Manage Columns (or Configure Columns, if in 3.0.x)
3) Click Actions Menu --> Save Columns
4) In 3.1.x, Sort priority is not saved or honored (problem #1), even though Manage Columns shows the sort value(s) that you entered. 3.0.x does seem to apply the sort order when you save it.
5) If you navigate away from the interface and then back, all sort values return to default & will show as 0 if looked at in Configure Columns (3.0.x) or Manage Columns (3.1.x) - Problem #2

Updating the title to reflect that this seems to be a larger problem.

summary: - Web Client: Sort Priority not honored in Check In and Capture Hold
- screens
+ Web Client: Sort Priority not honored in egGrid
Changed in evergreen:
status: New → Confirmed
Revision history for this message
Galen Charlton (gmc) wrote :

Patch that addresses the saving of the sort priority in 3.1.x is available here: collab/gmcharlt/lp1790169_eggrid_column_sort_wip. The branch remains WIP since the sort settings are not honored.

Revision history for this message
Andrea Neiman (aneiman) wrote :

Some more information about this in comments #3-#5 of bug 996744 (which I've marked duplicate)

Revision history for this message
Meg Stroup (mstroup) wrote :

We see this behavior in SCLENDS, and I will just add a little heat with this example of why sort is useful (from a reference librarian):

"It’s not bad when you have a patron with just a few items out, but the ILL account can have 20 to 40 items out at any one time. It’s helpful to sort by title to see what’s out."

Thanks to all who are working on this one.

Revision history for this message
John Amundson (jamundson) wrote :

In CW MARS, this problem is most apparent when viewing the Holds Pull List. Some of our libraries use the "Print Full Grid" option since it has access to more columns, (like Pickup Library), than the print template does.

However, since the move to 3.2, it has become impossible to do a secondary sort of any kind. (i.e. first Shelving Location then Call Number).

Revision history for this message
Andrea Neiman (aneiman) wrote :

Equinox is looking at this as part of a consultation for PaILS.

Revision history for this message
Jason Etheridge (phasefx) wrote :

So what I'm seeing (with Galen's patch in place), is that the Sort Priority only takes effect upon page load or if Manage Column Width is invoked.

I'm testing with Concerto and these barcodes in Item Status:

CONC90000936
CONC90000937
CONC90000938
CONC90000939
CONC90000940
CONC90000941
CONC90000942
CONC90000943
CONC90000944
CONC90000946

If we give the title column a sort priority of 1 and save the column configure, and reload the interface, then the grid will maintain those items in title order no matter what order they're scanned in. But if we don't save the columns and also reload the interface, then changes to sort priority are ignored.

So... it looks like compileSort is not getting invoked after closing the Configure Columns interface. If you change the sort priority, then invoke Manage Column Widths, compileSort does get called and the sort priority is honored.

I think this will fix it, and it includes a sign-off for Galen's commit:
collab/phasefx/lp1790169 @ working/Evergreen.git
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/phasefx/lp1790169

I haven't looked at eg2 yet, but I think this can go in as is.

Changed in evergreen:
assignee: nobody → Jason Etheridge (phasefx)
assignee: Jason Etheridge (phasefx) → nobody
tags: added: pullrequest
Andrea Neiman (aneiman)
Changed in evergreen:
milestone: none → 3.1.14
importance: Undecided → Medium
Remington Steed (rjs7)
Changed in evergreen:
milestone: 3.1.14 → 3.4-beta1
tags: added: eg-grid
Revision history for this message
Remington Steed (rjs7) wrote :

I've confirmed that the eg2 grid seems to need the same fixes. It looks like Galen already fixed the saving issue in eg2, so it only needs the equivalent of Jason's compileSort fix.

Revision history for this message
Remington Steed (rjs7) wrote :

And I've tested the AngularJS portions of this patch, and they work as described. Here's my signoff branch:

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

Remington Steed (rjs7)
tags: added: signedoff
Revision history for this message
Chris Sharp (chrissharp123) wrote :

Pushed to master, rel_3_3, and rel_3_2. Thanks, Galen, Jason, and Remington!

Changed in evergreen:
status: Confirmed → Fix Committed
Galen Charlton (gmc)
Changed in evergreen:
status: Fix Committed → Fix Released
Revision history for this message
Dan Wells (dbw2) wrote :

Since this bug is committed and partially released, I have opened #1844532 as a follow-up to address the eg2 problems Remington identified in comment #8.

Revision history for this message
Jeff Davis (jdavis-sitka) wrote :

The fix for this bug may be the cause of bug 1846038.

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

Duplicates of this bug

Other bug subscribers