Web client - random sort order of spine labels in preview & printed out

Bug #1775870 reported by Christine Burns
74
This bug affects 16 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
High
Adam Bowling
3.1
Confirmed
High
Unassigned
3.2
Confirmed
High
Unassigned

Bug Description

EG3.1

when we scan barcodes into Item Status, then chose “Print Labels” the labels do not come out in the order they were scanned in, instead they are in a random order.

We’ve tried putting the items into a copy bucket first, and printing from there but the results are the same.

Steps to reproduce

Scan barcodes into item status

CONC4000036
CONC4100053
CONC4100054
CONC4100055
CONC4100056
CONC61000236
CONC61000237
CONC61000238

items are listed in reverse order -> check box to select all -> Actions -> Print Labels

Label preview / print in this order

CONC61000237
CONC4100056
CONC61000236
CONC61000238
CONC4100055
CONC4100054
CONC4100053
CONC4000036

The random order creates a lot of extra work as we do not expect our processors to know which Dewey number applies to a particular book or item, instead for efficiency we have them apply the labels in the order they are on the cart.

Desired behaviour -> Spine labels should print in the order or reverse order they are scanned

Revision history for this message
Christine Burns (christine-burns) wrote :
Revision history for this message
Christine Burns (christine-burns) wrote :

** Note - the random sort order does not appear as bad with upstream test data. I wonder if the items are being sorted by database id or something?

tags: added: cataloging printing sorting
Changed in evergreen:
status: New → Confirmed
importance: Undecided → Wishlist
importance: Wishlist → High
Kathy Lussier (klussier)
tags: added: spinelabels
Adam Bowling (abowling)
Changed in evergreen:
assignee: nobody → Adam Bowling (abowling)
Revision history for this message
Adam Bowling (abowling) wrote :

The new code removes the random sort order of the labels, and sorts them in ascending order into the interface in the order in which they were populated from first to newest. If a user changes the sort order on a column in the grid supplying the copies to the interface (e.g. Barcode, Call Number, etc.), then those sort parameters become the order for sorting the copies.

Branch for testing pushed to http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=ae4b29cc87b9110b1dd8e060ab5bcb3c66b4a423

This branch is dependent on the customized label printing interface pushed to http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=ace4c873538c95459fdba5439a6167fe665551c1

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

Adam, your commit seems to have a lot of line changes that are only whitespace differences. That makes it a bit hard to see the real code changes. Are you able to push a new branch without the whitespace changes?

tags: added: pullrequest
Revision history for this message
Dan Pearl (dpearl) wrote :

Behavior is as expected.

user/dpearl/LP1775870_print_label_order-signoff

tags: added: signedoff
Revision history for this message
Dan Pearl (dpearl) wrote :

I did not observe the whitespace issue #4. Has this been resolved?

Revision history for this message
Terran McCanna (tmccanna) wrote :

Dan - yes, the whitespace was fixed as part of the overall layout updates

Revision history for this message
Terran McCanna (tmccanna) wrote :

It's still not working from Item Buckets or Holdings View - we are working with Adam to get those sorted before signing off.

tags: removed: signedoff
Revision history for this message
Elaine Hardy (ehardy) wrote :

The only place it is currently working is item status. However, it prints the labels in the opposite order than the item status list. So if list is :

1
2
3
4

It prints

4
3
2
1

For the check in screen, nothing happens when I choose print labels -- no error message and print labels don't display.

For item buckets and holdings view, attempting to print labels results in error message: could not create print label export. See attached screen shot.

Michele Morgan (mmorgan)
Changed in evergreen:
milestone: none → 3.3.4
Changed in evergreen:
milestone: 3.3.4 → 3.3.5
Revision history for this message
Adam Bowling (abowling) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.