Web Client: Copy Buckets Default Sort Seems to be Random

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

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

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

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.

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

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.

Confirmed still an issue in 3.5beta

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.

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

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.

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.

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.

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.

Confirmed still an issue in 3.7beta