Web Client: Copy Buckets Default Sort Seems to be Random

[Scott Thomas]

In the Web Client, when adding barcodes to Copy Buckets by scanning them into Pending Copies, they appear in the grid below in seemingly random order. In XUL they appear, unless another sort order is applied, in reverse order by time entered. The random ordering is problematic especially when trying to double-check a large number of items (for instance after being scanned from a book truck. The fact that the columns are not-sortable compounds the problem. I added a comment about the general sorting issue to bug 1437104 leaving this bug for the random ordering upon entry.

[Jennifer Pringle (jpringle-u)]

Confirmed that the random order and the inability to sort on the Pending Copies tab are both still present in 3.1

[Jennifer Pringle (jpringle-u)]

Based on preliminary testing the order may not be random but may in fact be sorting based on call number in 3.1.

[Jennifer Pringle (jpringle-u)]

Our libraries would prefer that they appear in the order they were entered so staff can double check that no items were missed.

[Jennifer Weston (jweston)]

Additional testing in 3.1 suggests sort order is based on Copy ID. Our libraries would also prefer that they appear in the order they were entered.

[Rose Schooff (rschooff)]

Our libraries also would like them to appear in the order they were scanned.

[Jennifer Pringle (jpringle-u)]

Confirming that scanning items into the Pending tab of Item Buckets still appears to sort them based on Copy ID (rather than displaying in the order scanned) in 3.3.3.

[Jennifer Pringle (jpringle-u)]

Confirmed still an issue in 3.5beta

[Mike Rylander (mrylander)]

Here's a branch that forces scan order on the pending tab: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1758381-copy-bucket-pending-order

From the commit message:

The order of rows in the pending list of copy buckets is currently undefined and, due to the way the query is constructed, looks random. This commit adds the ability to force a specific order on the contents of a grid and uses that ability to match the grid row order to the scan order.

[Jennifer Weston (jweston)]

Tested patch Terran loaded to test server. It does indeed appear to now order the items in the order scanned. Success! One note - XUL used to do this in reverse order by time entered. It was helpful to have the last one scanned at the top of the list rather than at the bottom but I'm not sure that's a show-stopper. Order scanned whether direct or reverse is certainly an improvement.
+1 to signing off on this as it is

[Terran McCanna (tmccanna)]

Thank you to Jennifer Weston, Jennifer Pringle, and Elaine Hardy for assisting in testing. I have added my sign off to:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=b393be680c784f6716fdb148dab87c697101d004

We will discuss the related questions at the next catalogers interest group meeting.

[Galen Charlton (gmc)]

This needs more work, as it breaks the grid if the user does one of the following:

- scan more items than the current row count limit
- reduces the row count limit to less than the number of items that have been scanned to date

There are at least two problems:

- The forceOrder processing makes $scope.item end up with as many rows as are in the pending list, not number of rows that are desired for display. The extra undefined objects in the array break the grid.
- Even if we try to fix the first problem, the fielder call doesn't guarantee that we'll get back all of the copies we're looking for, as it passes the ids of all of the copies in the pending list, but relies on the DB query's limit and offset clauses to return the desired copies; however, there's no guarantee that they'll match up.

[Jennifer Weston (jweston)]

Holding on repatch to fix grid breakage. No strong preference from CWG conversations relating to direct order versus reverse order. Direct order will be fine. We would like to see the order retained when transferring from pending into copy bucket.

[Wanangwa Hartwell (whartwell)]

I know I'm a little late on this discussion, but I do like the most recently scanned at the top. It makes it much easier to check, especially if you're scanning more items than what the field is set to show at the time.

[Christine Burns (christine-burns)]

Confirmed still an issue in 3.7beta