Currently, if you include "ccode","homebranch","holdingbranch","location", or "permanent_location" when printing labels, you'll end up with a code rather than a descriptive name/label. While I don't know how often you would necessarily use all of these, I have had a request come in for a label (instead of a code) for "homebranch" as they want their labels to include their library name. Makes sense to me. We already do it with item type. Collection code might be another one or location/permanent_location, depending on how they work their collections. "Holdingbranch" probably never but best perhaps to throw it in for good measure...
Created attachment 20520 [details] [review] Bug 10773 - Replace item-level codes with names/descriptions for Label Printing This patch replaces item-level codes for certain fields so that names and descriptions are printed out instead of codes when using the Label Creator. The fields in question are "ccode", "homebranch", "holdingbranch", "location", and "permanent_location". Test Plan: 1) Edit a layout in the Label Creator so that it includes any of these fields. I suggest including "homebranch" and perhaps "ccode" if you have them in your item data. 2) Add items to a batch in the Label Creator. 3) Export the batch using the layout, and view as PDF 4) Note how the codes for homebranch (and ccode if available) come up instead of the name of the homebranch (and ccode). 5) Apply patch 6) Export the batch again 7) Note how the branch name and category name are now displaying instead of the codes that showed before.
Created attachment 20541 [details] [review] Bug 10773 - Replace item-level codes with names/descriptions for Label Printing This patch replaces item-level codes for certain fields so that names and descriptions are printed out instead of codes when using the Label Creator. The fields in question are "ccode", "homebranch", "holdingbranch", "location", and "permanent_location". Test Plan: 1) Edit a layout in the Label Creator so that it includes any of these fields. I suggest including "homebranch" and perhaps "ccode" if you have them in your item data. 2) Add items to a batch in the Label Creator. 3) Export the batch using the layout, and view as PDF 4) Note how the codes for homebranch (and ccode if available) come up instead of the name of the homebranch (and ccode). 5) Apply patch 6) Export the batch again 7) Note how the branch name and category name are now displaying instead of the codes that showed before. Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Created attachment 21285 [details] [review] Bug 10773 - Replace item-level codes with names/descriptions for Label Printing This patch replaces item-level codes for certain fields so that names and descriptions are printed out instead of codes when using the Label Creator. The fields in question are "ccode", "homebranch", "holdingbranch", "location", and "permanent_location". Test Plan: 1) Edit a layout in the Label Creator so that it includes any of these fields. I suggest including "homebranch" and perhaps "ccode" if you have them in your item data. 2) Add items to a batch in the Label Creator. 3) Export the batch using the layout, and view as PDF 4) Note how the codes for homebranch (and ccode if available) come up instead of the name of the homebranch (and ccode). 5) Apply patch 6) Export the batch again 7) Note how the branch name and category name are now displaying instead of the codes that showed before. Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
One question, might it not still be useful to be able to print the codes directly for terseness? Since printing the code is the current default, perhaps these should be ccode_description, homebranch_description, etc instead? I have no idea if or how these codes are used in practice, so I do not feel qualified to make such a call, but I think it's a pertinent question at least.
(In reply to Kyle M Hall from comment #4) > One question, might it not still be useful to be able to print the codes > directly for terseness? Since printing the code is the current default, > perhaps these should be ccode_description, homebranch_description, etc > instead? I have no idea if or how these codes are used in practice, so I do > not feel qualified to make such a call, but I think it's a pertinent > question at least. Certainly a pertinent question, Kyle! I was pondering it last week a little bit. I was wondering if any libraries print their branch code on their spine label or on other labels they might apply to resources. I would think that printing on the spine label would be a bizarre choice, but I suppose one never knows... I like the idea of "ccode_description, homebranch_description, etc.", although I can't remember how straightforward those would be to implement. Still, as you say, since the code is the current default, it might make more sense to add a new option rather than changing the default. If this change were pushed, we might find some libraries quite surprised that their labels suddenly are very different. As far as I know, I only have one library using the branch code, and they're the ones who wanted the description, but like I was saying...you never know. I'll have to ponder this one some more at some point...
Created attachment 34539 [details] [review] Bug 10773 - Add item-level descriptions for Label Printing This patch adds new fields ccode_description, homebranch_description, holdingbranch_description, location_description and permanent_location_description which can be used in the Label Creator to display names/descriptions instead of codes Test Plan: 1) Edit a layout in the Label Creator so that it includes any of these fields. I suggest including "homebranch_description" and perhaps "ccode_description" if you have them in your item data. 2) Add items to a batch in the Label Creator. 3) Export the batch using the layout, and view as PDF 4) Verify that you see descriptions for fields which you added
Adding all new fields as *_description wasn't that hard after all, and since we also need holdingbranch_description for one of our libraries I decided to throw my hat into ring and write patch with implements it.
Created attachment 34634 [details] [review] Bug 10773 - add help for *_description fields
(In reply to Dobrica Pavlinusic from comment #8) > Created attachment 34634 [details] [review] [review] > Bug 10773 - add help for *_description fields Typo "Fileds" in there
Created attachment 35031 [details] [review] Bug 10773 - add help for *_description fields
(In reply to paxed from comment #9) > (In reply to Dobrica Pavlinusic from comment #8) > > Created attachment 34634 [details] [review] [review] [review] > > Bug 10773 - add help for *_description fields > > Typo "Fileds" in there Thanks, fixed.
Created attachment 36051 [details] [review] [SIGNED OFF] Bug 10773 - Add item-level descriptions for Label Printing This patch adds new fields ccode_description, homebranch_description, holdingbranch_description, location_description and permanent_location_description which can be used in the Label Creator to display names/descriptions instead of codes Test Plan: 1) Edit a layout in the Label Creator so that it includes any of these fields. I suggest including "homebranch_description" and perhaps "ccode_description" if you have them in your item data. 2) Add items to a batch in the Label Creator. 3) Export the batch using the layout, and view as PDF 4) Verify that you see descriptions for fields which you added Signed-off-by: Nick <Nick@quechelibrary.org>
Created attachment 36052 [details] [review] [SIGNED OFF]Bug 10773 - add help for *_description fields Signed-off-by: Nick <Nick@quechelibrary.org>
Created attachment 36085 [details] [review] [PASSED QA] Bug 10773 - Add item-level descriptions for Label Printing This patch adds new fields ccode_description, homebranch_description, holdingbranch_description, location_description and permanent_location_description which can be used in the Label Creator to display names/descriptions instead of codes Test Plan: 1) Edit a layout in the Label Creator so that it includes any of these fields. I suggest including "homebranch_description" and perhaps "ccode_description" if you have them in your item data. 2) Add items to a batch in the Label Creator. 3) Export the batch using the layout, and view as PDF 4) Verify that you see descriptions for fields which you added Signed-off-by: Nick <Nick@quechelibrary.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 36086 [details] [review] [PASSED QA] Bug 10773 - add help for *_description fields Signed-off-by: Nick <Nick@quechelibrary.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
*** Bug 12553 has been marked as a duplicate of this bug. ***
Bumping the priority on this as it is causing issues for several folks at this point. It would be good to get this into the next release.
I would say this is an enhancement. But, anyway, Chris N. is about to post a followup with regression tests, so I'll be holding this until then.
(In reply to Tomás Cohen Arazi from comment #18) > I would say this is an enhancement. This is not the intended nor expected behavior which makes me lean toward it being a true bug. > But, anyway, Chris N. is about to post a > followup with regression tests, so I'll be holding this until then. FTR, here are my current thoughts on this: This is going to be a bit of a problem to try to mock. Notice here: http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=C4/Labels/Label.pm;h=bd3ee4fe7bbdc723d9b8b13bbb22ba8da3686086;hb=HEAD#l81 we grab all of the data in 4 tables. I know that DBD::Mock allows mocking resultsets, but this would require a significant amount of coding, and it is not clear whether DBD::Mock will handle a join or not. The way I read the docs, it will not. I think the only way to do this is to make it run over a test database which means it will not be run as part of the standard test suite. I will be glad to write up a test for this, but question the value of it if it will not be run as a part of the standard test suite.
Chris, tests on t/db_dependent are considered standard and are always run by the dev team and jenkins too, when pushed.
Patches pushed to master. Thanks Dobrica!
Pushed to 3.18.x will be in 3.18.6
Finally took the time to look at this one again... thanks indeed Dobrica!