webstaff item print labels

Bug #1704873 reported by Jason Etheridge on 2017-07-17
This bug affects 2 people
Affects Status Importance Assigned to Milestone

Bug Description


Webstaff version of the spine/pocket label interface, but given a more generic name of item print labels.

Entry points:

* Item Status, List View -> Actions -> Print Labels
* Copy Buckets -> Actions -> Print Labels
* Staff OPAC, Holdings -> Actions -> Print Labels
* vol/copy editor, Defaults -> Print Item Labels on Save & Exit

UI description:

* template management system at the top (Save, Delete, Apply, Export, etc.)$a
* also at the top, printer selection and the Print button
* Label Preview pane on the right (completely rendered)
* tabbed interface on the left, with these tabs:
  - Call Number Template
  - Call Numbers
  - Settings
  - Label Template

Call Number Template:

Stock template here mimics the spine label behavior from the XUL client. It pulls from two Library Settings, "Item Print Label - Call Number Wrap Filter Height" and "Item Print Label - Call Number Wrap Filter Width", given in lines and characters, respectively. It pulls in call number affixes, and copy location affixes. It also considers the call number classification. One normally wouldn't need to edit this specific template, but it's Angularized HTML.

Call Numbers:

A textbox for each unique rendered/formatted call number from the Call Number Template. Manual adjustments may be made here, and these edited call numbers are ultimately used by the Label Template. Changes here do not get saved or made by the templating system at the top of the UI.


A slew of settings that get used by the Call Number Template and Label Template, with defaults coming from corresponding Library Settings. Changes here are managed by the templating system at the top of the UI. The new library settings are independent of the old label settings for the XUL client. Except for the two settings mentioned with the Call Number Template, these settings use CSS rules for specifying units of measure.

Label Template:

The stock template here implements the default spine and pocket label behavior from the XUL client. Output from it is rendered into the Label Preview pane. Changes may be previewed live; there is no Re-Generate and "Print and Preview" button as in the XUL client.

Jason Etheridge (phasefx) wrote :

We've given this some light testing with laser printers without using Hatch. Wider testing would be much appreciated, as well as bug reports.

Let me know what you think. Thanks!

I think down the road folks may want to add a Simple Template tab for rearranging elements without needing to know HTML/CSS. It would probably also be worthwhile to implement a sheet label printing example within the Label Template.

tags: added: pullrequest
Changed in evergreen:
milestone: none → 3.0-alpha
Bill Erickson (berick) on 2017-07-19
Changed in evergreen:
status: New → Confirmed
Bill Erickson (berick) on 2017-07-19
Changed in evergreen:
assignee: nobody → Bill Erickson (berick)
Bill Erickson (berick) wrote :

1. Confirmed basic functionality for tweaking, saving, and applying templates.
2. Confirmed printing via Hatch behaves as expected.
3. Quick code review, no dragons.
4. Confirmed Export generated a sane looking output.
5. I did not test import.

This is an interface I practically never use, so ideally others will test.


I pushed a new branch:


1. Includes sign-off for Jason's commit.

2. Adds an extra commit to smooth some UI funkiness. The 'Template' and 'Printer' labels were squashed and partially hidden for me. I reworked the labels to behave more like and/or use input group add-ons so they are attached to their selector widgets and remain visible. This includes adding support for an optional drop-down button label in <eg-basic-combo-box/>

Changed in evergreen:
assignee: Bill Erickson (berick) → nobody
Mike Rylander (mrylander) wrote :

Thanks Bill. One thing about the combo box -- it grew the ability to have a placeholder attribute on the text input in the combined serials branch. Would that suffice instead of a label for the dropdown, or do we want both?

Bill Erickson (berick) wrote :

That actually raises another question.. The "Default" button appears to reload the default template from the server. Is there a way to save a locally created template as the browser-local default? I ask because I think the placeholder text would suffice if the combo box text contained no value (showing the placeholder) with each page load. If a template is ever applied on page load, masking the placeholder text, we might want to keep the new label.

Cesar V (cesardv) wrote :

Guys, in 1685929, it asks for the ability to Print Spine Labels from the CheckIn grid of the web staff.
Can that be added to the scope of this task, as an additional entry point?

Cesar V (cesardv) wrote :

Currently testing and merging code from 1685929 with the stuff in user/berick/lp1704873-webstaf-print-label-review ...

I'll likely push an integration branch since on 1685929 felt it was best to extract and DRY up the itemSvc service from item/app.js into it's own separate service "egItem" that lives in staff/circ/services/item.js
That code is in user/cesardv/lp1685929_checkin_actions_itemSvc

Cesar V (cesardv) wrote :

After discussion with Jason, I will just add enough code so that it's trivial, once this ticket's code hits master, to change my code in order to implement printing spine labels from Check-in grid.

This way both tickets are more or less independent of one another.

So scratch my last comment.

Jason Etheridge (phasefx) wrote :

Bill, do you think we could hold off on more dramatic widget changes for a later branch that makes use of that pattern everywhere (for example, the item editor, which I cribbed from)? I'm sympathetic to any experience of wonkiness.. right now with your branch I get wonkiness of my own with lower window widths, where the Template Apply button squishes next to the Printer selector and tricks me into thinking it doesn't go with templates. I also like the pattern where you can click on the label and have focus jump to the widget, though apparently I didn't do that with this one.

With the Default button, my intention (and it looks like I overlooked this too) was to have the last template applied be sticky and auto-apply on subsequent page loads, to save clicks with repeat workflows. The XUL client is sticky on any field change, though I don't want to go that far. I'm okay with a blank (or even a labelled) menu entry in the Template selector serve the same function as the Default button (though we might would want to disable the Save/Delete buttons for that selection), and any move in this regard is more than the XUL client has, at least, but I think we should have some consistency with other template editing interfaces. What do other folk think?

Changed in evergreen:
assignee: nobody → Jason Etheridge (phasefx)
tags: removed: pullrequest
Bill Erickson (berick) wrote :

Jason, +1 to addressing display funkiness in a more holistic fashion after this code is merged.

Jason Etheridge (phasefx) wrote :

Thanks Bill! Hrmm, so I started to implement the "auto-apply last applied template" strategy, and quickly realized that I had already implemented a sort of stickiness and forgot about it. The difference is that it's not based on applied templates, and it basically only saves when you actually click the Print button.

I'm not sure I like that behavior in retrospect. Do folks think I should keep that or rip it out and go with the "auto-apply last applied template" idea? The latter might be more obvious to end-users, particularly if we default the template selector to the template being auto-applied.

Jason Etheridge (phasefx) wrote :

Another option is to just add a "Use Current Settings as Default" button and fire the save on that instead of Print.

Jason Etheridge (phasefx) wrote :

In that case, I'd be tempted to consolidate some of those buttons into a menu.

Andrea Neiman (aneiman) wrote :

+1 to making the last template used workstation-sticky in this interface, especially if as Jason noted the template selector indicates the template being loaded. Reasoning that a cataloger is likely to be processing a batch of similar items at once.

Also +1 for a future consolidation of buttons in this interface into an action menu, but that could be its own LP item if it's thought that further discussion as needed.

Jason Etheridge (phasefx) wrote :

Thanks Andrea. I've pushed an extra commit onto my original branch that implements the sticky behavior:


There's a bit of kludginess here in that I'm using the print service to actually store the modified templates and settings on Apply, and not _actually_ auto-applying the last used template, though I am auto-selecting that template in the dropdown. Together we get the illusion that it's being auto-applied, and I'm okay with that (someone would have to modify localStorage/hatch directly to break the illusion).

tags: added: pullrequest
Bill Erickson (berick) wrote :

Jason, just to be clear, the commit I signed off on ("webstaff: label printing") is the same as the first commit in your most recently posted branch? Or was the sign-off jettisoned due to code changes?

Jason Etheridge (phasefx) wrote :

Bill, I went back to the original branch and added an extra commit, though in retrospect it would have made sense for me to have pulled in your signed commit into a new branch to work off of (if having argued against your additional commit didn't invalidate your approval of mine). I didn't change what was in the "webstaff: label printing" commit. Clear, or did I confuse things more?

Andrea Neiman (aneiman) wrote :

Tested this & loading last printed label template is working for me though I would appreciate another set of eyes for testing & signoff.

Bill Erickson (berick) wrote :

Got it, Jason. And thanks for testing, Andrea. Grabbing for another review.

Changed in evergreen:
assignee: Jason Etheridge (phasefx) → Bill Erickson (berick)
Bill Erickson (berick) wrote :

Confirmed stickiness of last used template. Exercised more of the manual settings overrides with expected results. Looks good! Merged to master. Thanks.

Changed in evergreen:
assignee: Bill Erickson (berick) → nobody
status: Confirmed → Fix Committed
Galen Charlton (gmc) on 2017-08-25
Changed in evergreen:
importance: Undecided → Medium
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers