Bug 7615 - Give option to use description for homebranch/holding branch in label creator instead of the branchcode
Summary: Give option to use description for homebranch/holding branch in label creator...
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Label/patron card printing (show other bugs)
Version: 3.8
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Chris Nighswonger
QA Contact: Ian Walls
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-28 17:53 UTC by Shane Sammons
Modified: 2013-12-05 20:04 UTC (History)
3 users (show)

See Also:
Change sponsored?: Sponsored
Patch complexity: ---
Text to go in the release notes:
Version(s) released in:


Attachments
Patch to add 'branchname' to label fields (3.29 KB, patch)
2012-02-29 00:31 UTC, Chris Nighswonger
Details | Diff | Splinter Review
Bug 7615 - Give option to use description for homebranch/holding branch in label creator instead of the branchcode (3.36 KB, patch)
2012-02-29 15:56 UTC, Liz Rea
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Shane Sammons 2012-02-28 17:53:12 UTC
It would be very helpful to be able to retrieve the description of the location codes for the label. Often a barcode label is used to identify a books location at a glance.

Currently it only retrieves the code. I would assume this could be an addition field like homebranch_desc that just uses SQL to return the description field.
Comment 1 Shane Sammons 2012-02-28 18:44:19 UTC
If it helps at all I made an SQL statement and tested it after finding a books ID..

SELECT B.branchname FROM branches as B, items as I WHERE I.itemnumber = <itemnumberhere> AND I.homebranch = B.branchcode
Comment 2 Shane Sammons 2012-02-28 20:28:10 UTC
I attempted modifying C4/Labels/Label.pm with the following code:
http://pastebin.com/ccJMk89G

It did not break anything (that I can tell), but did not make available any extra fields such as branchname from the branches table.

I tested the SQL in MySQL command line, and it worked when replacing the "?" with an itemnumber. All the related data from branches was added to the resulting data in MySQL.
Comment 3 Chris Cormack 2012-02-28 20:42:05 UTC
Thats looking really good Shane ... now .. do you think you might to try crafting a patch to send? Get your name in the Koha credits ? :)

http://wiki.koha-community.org/wiki/Version_Control_Using_Git
Comment 4 Shane Sammons 2012-02-28 20:59:35 UTC
I would learn how, but that is not working :(. I mean it works in MySQL, but the label.pm does not seem to be utilizing the new fields and I am not sure why.
Comment 5 Chris Nighswonger 2012-02-29 00:31:01 UTC Comment hidden (obsolete)
Comment 6 Chris Nighswonger 2012-02-29 00:32:48 UTC
This patch also fixes a minor bug in a mistaken variable re-declaration which was flooding the log.
Comment 7 Liz Rea 2012-02-29 15:56:43 UTC
Created attachment 7945 [details] [review]
Bug 7615 - Give option to use description for homebranch/holding branch in label creator instead of the branchcode

This patch adds the ability to print the name of the item's homebranch on labels

Thanks to Shane Sammons <ssammons-at-npelem.com> for the modified SQL SELECT statement.

Document Manager: The documentation will need to be updated to reflect the added field 'branchname' to the list
of available fields for label printing.

To test:

1. Create a new label layout or modify an existing one to include 'branchname'
2. Create a new label batch or using an existing one, export the batch.
3. Verify that the resulting labels contain the home branch name for the respective items.

Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Tested with the plan - works
Passes prove t xt
Comment 8 Ian Walls 2012-03-02 16:05:31 UTC
Adds all branches fields to possible values, which includes not only branchname, but also all branch contact info (address, email, phone, fax), branch IP, and branch notes.  Makes the implicit assumption that Homebranch should be used, but for labeling of materials, that seems like the correct bet.

Marking as Passed QA.
Comment 9 Paul Poulain 2012-03-08 15:13:19 UTC
QA comment:

the SQL query was ugly and would have been worth being rewritten:
* we should never return biblioitems.* because there's marcxml that can be quite large ! (even if it's less true now that items are no more stored here)
* the query should be written SELECT * FROM a LEFT JOIN b USING(somekey) and not SELECT * FROM a,b WHERE a.key=b.key.

I won't mark failed QA because the query was already like this, but for next commits, it's worth rewritting the SQL !
Comment 10 Chris Nighswonger 2012-03-08 15:26:14 UTC
I concur 100%. When doing the labels rework several years ago, I added a comment to this effect. Reworking the SQL here, however, will also require a full understanding of the entire scope of data the user might expect. At the time, someone at LibLime (I don't remember who) had some objections to improvements on the SQL I proposed, so I left it alone.
Comment 11 Shane Sammons 2012-03-08 16:06:58 UTC
I agree as well, I just followed what existed.

Should we open a new bug to "discuss" what fields would and wouldn't be used?

Would it be hard to "patch" for extra field should we find users need more after making restrictions?
Comment 12 Liz Rea 2012-03-08 19:48:11 UTC
Also, we need to remember to add Shane to the contributors in the history and the About. :)
Comment 13 Liz Rea 2012-03-08 19:52:16 UTC
oh wait, chris_n did that. Boo. :)
Comment 14 Jared Camins-Esakov 2012-12-31 00:42:30 UTC
There have been no further reports of problems so I am marking this bug resolved.