Cumulative Fixes for Spine Label Display

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
FIC
PATTERSO

it is now:

FIC PA
TTERSO

and

FIC
PAT

is now
FIC PAT

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

31001001055376

31001001320572

31001004671773

31001004671781

Print spine label call number tab displays as:

31001004671781

31001004671773

31001001320572

31001001055376

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?

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

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?

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.
Josh

Here's the latest patch for testing.

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

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.

Here's the test branch for the LC number wrap testing.

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

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?

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.

The latest (tested) branch addressing the enhanced spine label printing features.

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

Whoops! Missed adding the template view to the repo. Here's the latest.

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

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.

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

Repatched and cleaned up version. *Think* it's ready for pull.

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

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:
MT130M
812345
665432
G3

and

"780.1234566543212346 B2" becomes
780
.12345
665432
12346
B2

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.

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?

Rebase of code pushed.

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

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.

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

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?

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:
EASY
READER
E

Output before this fix gets applied:
EASY REA
DER E

Fix is to add in a substitution that turns spaces into tabs in the prefix.
https://git.evergreen-ils.org/?p=working/Evergreen.git;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.)

Latest code rebase fixing the sorting issues.

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

Latest is at:

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

It's still not working from an Item Bucket.

I can firm print label interface is not populating from item bucket. The tab opens but the call numbers don't.

It does load from holdings view in a bib record. Sorting is as desired here -- order of items in individual record

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

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

PINES has tested the latest branch on current master (3.8-ish) and are happy with the functionality. My sign off is at:

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

The latest patch series is not working for me. In particular, when I try printing a label from Item Status' Detail View, I get the following error:

ReferenceError: gatherSelectedHoldingsIds is not defined
    print_spine_labels https://192.168.1.85/js/ui/default/staff/circ/services/item.js:998
    print_labels https://192.168.1.85/js/ui/default/staff/cat/item/app.js:98
    fn https://192.168.1.85/js/ui/default/staff/build/js/vendor.bundle.js line 6 > Function:4
...

I get the same error trying to print labels from the checkin page.

Attempting to fix this by editing print_spine_labels() in services/item.js by changing to "gatherSelectedHoldingsIds()" to "service.gatherSelectedHoldingsIds()" isn't enough. After making that change, a significant problem remains: the service does not have access to a $scope, and the function is ignoring the copy_ids parameter passed to it.

service.print_spine_labels() may not have need a change at all in favor of having the caller sort the items as needed.

In any event, this needs more work, so I've marked this bug as such.

Adam's latest is at https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/abowling/lp1845556_spine_label_enhanced_printing_final_01_2022

It looks like it fixes the remaining errors in #31 in our testing, so I'll re-add the pullrequest.

I have tested this code )(ncluding printing from item status detail view and checkin) and consent to signing off on it with my name, Elaine Hardy and my email address, <email address hidden>.

Nope, scratch that. Elaine identified some old issues that were fixed in an earlier version that cropped up again. Mainly, call number wrapping and the inability to edit on the fly.