Summary: | copynumber, location not printing correctly on spine labels. | ||
---|---|---|---|
Product: | Koha | Reporter: | Barton Chittenden <barton> |
Component: | Label/patron card printing | Assignee: | Chris Nighswonger <cnighswonger> |
Status: | RESOLVED DUPLICATE | QA Contact: | Testopia <testopia> |
Severity: | major | ||
Priority: | P3 | CC: | nick |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: | http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10773 | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: | |||
Attachments: | label_batch_8.pdf -- spine label output. |
Description
Barton Chittenden
2014-07-10 21:49:24 UTC
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. |