Created attachment 29617 [details] label_batch_8.pdf -- spine label output. I have verified that the problem exists on the bywater example site. Here are the steps that I used to replicate the problem: 1) Log in to http://intranet.bywatersolutions.com username: bywater password:bywater 2) Go to Home > Tools > Labels home > Manage label Templates: ( http://intranet.bywatersolutions.com/cgi-bin/koha/labels/label-manage.pl?label_element=template ) 3) Create a new template with the following fields template_code: GAYLORD_20000590_SL units: INCH template_desc: 1 5/8'' x 7/8'' Spine labels page_width: 8.5 page_height: 11 label_width: 0.875 label_height: 1.625 top_text_margin: 0.31 left_text_margin: 0.3 top_margin: 0.13 left_margin: 0.1 cols: 2 rows: 6 col_gap: 3.3 row_gap: 0.29 creator: Labels 4) Click 'Manage layouts' 5) Check the 'select' box for 'spine' layout, then click 'edit' 6) Check 'List Fields' radio button, then enter itemcallnumber, copynumber, location In the 'Data fields' text box. 7) Click the 'New Batch' button 8) Add the barcodes TVSN5000326266 and TVSN5000226254 to the 'Add by barcode(s)' text box, click the 'Add item(s)' button. 9) Click the 'Export batch' button 10) Select GAYLORD_20000590_SL as 'template to be applied' 11) Select 'spine' as 'layout to be applied' 12) Click 'Export' 13) Click 'Download as PDF' The resulting pdf Will have two labels, which read as follows: 598 Aud 0 0 JBIO Opp 0 0 These should read: 598 Aud 1 AUD and JBIO Opp 1 BIO Respectively.
I have a second partner who has seen this. Pushing priority.
An inital look at this shows up the following: 1. The symptom manifests in bywatersolutions.com instance as described. 2. It partially manifests on my local dev box running over the current HEAD. I say partially, because the copy number does display correctly on my dev box with the caviate that it is always '1' because the code presently does not distinguish between items. I'm not sure why it is always '0' on the Bywater instance. The problem with the location is that the current code does not return the human-consumable form of the location, it appears to return the So there are two parts to this bug: 1. The copy number needs to be the correct one for the item selected in the batch. 2. We need to add a join in order to translate the location code into a form more palatable to the end user. All of this happens here: http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=C4/Labels/Label.pm;h=bd3ee4fe7bbdc723d9b8b13bbb22ba8da3686086;hb=HEAD#l175 The addition of some code to that sub should fix the problem.
Bumping importance.
*** This bug has been marked as a duplicate of bug 10773 ***