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.
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
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.
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
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.
Created attachment 7935 [details] [review] Patch to add 'branchname' to label fields 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.
This patch also fixes a minor bug in a mistaken variable re-declaration which was flooding the log.
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
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.
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 !
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.
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?
Also, we need to remember to add Shane to the contributors in the history and the About. :)
oh wait, chris_n did that. Boo. :)
There have been no further reports of problems so I am marking this bug resolved.