Cumulative Fixes for Spine Label Display

Bug #1845556 reported by Adam Bowling on 2019-09-26
This bug affects 16 people
Affects Status Importance Assigned to Milestone
Adam Bowling

Bug Description

Cumulative fixes for spine label display and editing issues, including:

-Random spine label display order (
-Unique call number editing limitation (
-Incorrect display of long call numbers (;a=commit;h=fc211855c5a4e95240fae49fd96d555c47b6cff8

tags: added: printing spinelabels
tags: added: cataloging pullrequest
Elaine Hardy (ehardy) wrote :

Tested this on PINES servers.

Still getting an error message when I try to open print labels from an item bucket. In Chrome, the error is: Could not create print label export. Firefox has a similarly worded error message.

I can print labels from holdings view and item status

I can now edit a single call number where multiple identical ones exist in a file while in the call number tab of the print labels interface. However, the call numbers no longer have the correct default wrap.

Instead of

it is now:




is now

The sort/display order also seems to have regressed. If the order in item status is:





Print spine label call number tab displays as:





tags: removed: pullrequest
tags: added: needsrepatch

EG 3.3.4

I'm testing out the ordering fixes included in this, specifically for the check-in interface.

And those do seem to work. When creating labels from multiple items in the check-in interface, they print in the correct order.

But the changes to Open-ILS/web/js/ui/default/staff/cat/printlabels/app.js
seem to now wipe out custom label template settings (Content in the json) whenever the template is applied. Which seemed to work fine before these changes.

1. Open up Print item labels from item stats.
2. Choose template and apply.
3. Switch to "Label Template" tab.
4. Make Changes to template - in my case get rid of author and allow long titles, and add output after last </pre> tag.
5. Preview shows changes.
6. Click Save to save the changes.
7. Click Print - printout doesn't reflect changes.
8. Click Apply to apply the template just saved.
9. Template is reset to default.

So it is strange that preview and print are not linked. And that saving, then applying a template don't work.

When I export the saved template, before applying it, I do see the changes to the content in the file.

So is there something that is now overwriting the label template before printing?

Terran McCanna (tmccanna) wrote :

FYI, Adam is working on the remaining issues on this.

Changed in evergreen:
assignee: nobody → Adam Bowling (abowling)
Chris Sharp (chrissharp123) wrote :

Working with Terran and Adam in person right now, we are unable to recreate the error message Elaine reported. Adam will be coding a fix for the label wrapping issue.

Josh, we were unable to recreate your issue running Adam's fixes on current master. We suspect that maybe the old settings were being cached somehow? Also, running atop 3.3 may present additional factors that complicate the situation. Could you please report back about it?

Chris Sharp (chrissharp123) wrote :

I'm confirming the sorting problem. When I pick a set of items with Dewey call numbers, and open them in the spine label printing editor, they are not coming in in the set order.

Chris - Thanks for testing that out. I'm sure you are correct that the issues I was seeing were because of my attempt to apply the fix to 3.3.

We needed the order fixes for printing labels from the check-in interface, I was able to figure how to just apply those fixes to our 3.3 system so that staff could use the web client for our specific use case. (we use the spine label printing feature to print labels for DVDS that are kept separate from the cases for theft prevention).

I'm not sure I'll have a chance to test a master system soon though, so if you are not seeing the same issue I wouldn't wait on me about it.

Terran McCanna (tmccanna) wrote :

PINES has tested this on a test server with a copy of our real data and we're happy with it, but we use Dewey and not LC. If there is a library using LC that can test to be sure LC call numbers are sorting and wrapping correctly, please do.

Jeff Davis (jdavis-sitka) wrote :

We're interested in testing this, but the latest branch from comment #9 seems to make a lot of changes that are unrelated to spine label improvements. For example, it removes the moveToPending function from Open-ILS/web/js/ui/default/staff/cat/bucket/copy/app.js, which was added for bug 1735835. It also strips the l() function from some strings, making them untranslatable. I wonder if an old working branch was overlaid on top of a newer version of EG, accidentally undoing some more recent changes to EG in the process?

Adam Bowling (abowling) wrote :

Jeff, it's quite likely. This dev/re-dev spanned over more than one upgrade. It's likely some old stuff remained sticky in the posted branch. I'll look into it and make it current.

Adam Bowling (abowling) wrote :

The latest (tested) branch addressing the enhanced spine label printing features.;a=commit;h=0f10561b3b3e8321d4ebb00e92e06f07c2dcbef3

tags: added: pullrequest
Adam Bowling (abowling) wrote :

Whoops! Missed adding the template view to the repo. Here's the latest.;a=commit;h=cd31ce39a61ef2a1397f4195cd088445e32fa12a

tags: removed: needsrepatch
Jason Boyer (jboyer) wrote :

Hi Adam, I was giving this a quick glance and I found a couple issues:

There's a regression in the init_cat_url function in Open-ILS/web/js/ui/default/staff/cat/catalog/app.js. Removing the \/ from the advanced -> record / result url_replace calls reverts bug 1858701.

There's still a console.log("brick01") in Open-ILS/web/js/ui/default/staff/cat/printlabels/app.js that will need to come out.

The second diff chunk in Open-ILS/src/templates/staff/cat/printlabels/t_view.tt2 is labeled PINES customization which is fine for PINES but no good for inclusion in core.

There are also a few /eg2/staff/catalog -> /eg/staff/catalog changes but I'm assuming that's just going to be a difference between the 3.4/3.5 branches and master.

tags: added: needsrepatch
tags: removed: pullrequest
Adam Bowling (abowling) wrote :

Thanks for the notes, Jason. Working to address. Will get them updated.

Adam Bowling (abowling) wrote :
tags: added: pullrequest
removed: needsrepatch
Galen Charlton (gmc) on 2020-09-03
Changed in evergreen:
importance: Undecided → Medium
Jason Boyer (jboyer) wrote :

I took another look at this today. The code is definitely cleaner but I ran into some issues testing it out.

When I tried to print multiple labels from the item status screen they did indeed appear in the correct order in the Call Numbers tab but the Label Preview was reversed.

I tested editing call numbers in the Call Numbers tab and had multiple issues with the Wrap Height and Wrap Width. The wrap width appears to be hard-coded at 6 characters

"MT130M812345665432 G3" becomes:


"780.1234566543212346 B2" becomes

When changing the value for wrap height or wrap width any edits made on the call numbers tab are lost. Additionally the wrap values don't appear to take effect because whether I change the wrap width to 4 or 12, it still wraps on 6. Similar for the wrap height.

tags: added: needsrepatch
removed: pullrequest
Adam Bowling (abowling) wrote :

Thanks for the notes, Jason. As far as the manual edits issue goes, that it is a legacy feature from 3.0 that existed before these changes. I don't allege that this isn't a buggish feature, but I'd argue it's outside of the scope of this feature, given its pre-existing condition-ness.

Re: the wrap issues, I believe you, but I am unable to recreate. Is there a test instance available or might you be interested in doing a remote that you can show me?

Adam Bowling (abowling) wrote :

I felt I haven't posted enough version updates to this. The previous version omitted updates to Open-ILS/web/js/ui/default/staff/cat/item/app.js since the additions to the latter.;a=commit;h=440dd73b9122bfd495b1898e0d092fd70aec3648

Jeff Davis (jdavis-sitka) wrote :

Adam, it looks like instead of rebasing, your latest commits add a bunch of changes to your branch that aren't spine label-related, including some PINES customizations. Can you isolate the actual spine label fixes and put them in their own commit without any extraneous changes?

Adam Bowling (abowling) wrote :

Jeff, tired commits lead to that sort of thing. Sure thing.

I believe that this work addresses the issue with call number prefixes being wrapped incorrectly. But if anyone needs a local fix before this gets to them, here is a simple one line change that goes back to the old behavior. This was keeping us from using the web client spine label printing because we use long expressive call number prefixes.

Prefix = "EASY READER E"

Expected output:

Output before this fix gets applied:

Fix is to add in a substitution that turns spaces into tabs in the prefix.;a=shortlog;h=refs/heads/user/stompro/web_client_spine_label_prefix_wrap_fix

(I apologize if adding something like this to a bug report is frowned upon.)

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

Other bug subscribers