Bug 10773 - Add item-level descriptions for Label Printing
Summary: Add item-level descriptions for Label Printing
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Label/patron card printing (show other bugs)
Version: master
Hardware: All All
: P3 enhancement (vote)
Assignee: Dobrica Pavlinusic
QA Contact: Testopia
URL:
Whiteboard:
Keywords:
: 12553 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-08-21 05:15 UTC by David Cook
Modified: 2017-06-14 22:08 UTC (History)
9 users (show)

See Also:
Change sponsored?: Sponsored
Patch complexity: Trivial patch
Bot Control: ---
When did the bot last check this:
Who signed the patch off:
Text to go in the release notes:


Attachments
Bug 10773 - Replace item-level codes with names/descriptions for Label Printing (2.43 KB, patch)
2013-08-21 05:24 UTC, David Cook
Details | Diff | Splinter Review
Bug 10773 - Replace item-level codes with names/descriptions for Label Printing (2.50 KB, patch)
2013-08-21 15:35 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 10773 - Replace item-level codes with names/descriptions for Label Printing (2.53 KB, patch)
2013-09-20 18:02 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 10773 - Add item-level descriptions for Label Printing (2.11 KB, patch)
2014-12-19 13:55 UTC, Dobrica Pavlinusic
Details | Diff | Splinter Review
Bug 10773 - add help for *_description fields (1.40 KB, patch)
2014-12-22 14:09 UTC, Dobrica Pavlinusic
Details | Diff | Splinter Review
Bug 10773 - add help for *_description fields (1.40 KB, patch)
2015-01-08 11:46 UTC, Dobrica Pavlinusic
Details | Diff | Splinter Review
[SIGNED OFF] Bug 10773 - Add item-level descriptions for Label Printing (2.15 KB, patch)
2015-02-19 20:08 UTC, Nick Clemens
Details | Diff | Splinter Review
[SIGNED OFF]Bug 10773 - add help for *_description fields (1.46 KB, patch)
2015-02-19 20:09 UTC, Nick Clemens
Details | Diff | Splinter Review
[PASSED QA] Bug 10773 - Add item-level descriptions for Label Printing (2.22 KB, patch)
2015-02-20 14:04 UTC, Kyle M Hall
Details | Diff | Splinter Review
[PASSED QA] Bug 10773 - add help for *_description fields (1.51 KB, patch)
2015-02-20 14:04 UTC, Kyle M Hall
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description David Cook 2013-08-21 05:15:41 UTC
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...
Comment 1 David Cook 2013-08-21 05:24:36 UTC Comment hidden (obsolete)
Comment 2 Owen Leonard 2013-08-21 15:35:24 UTC Comment hidden (obsolete)
Comment 3 Kyle M Hall 2013-09-20 18:02:09 UTC Comment hidden (obsolete)
Comment 4 Kyle M Hall 2013-09-20 18:05:30 UTC
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.
Comment 5 David Cook 2013-09-22 23:56:37 UTC
(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...
Comment 6 Dobrica Pavlinusic 2014-12-19 13:55:37 UTC Comment hidden (obsolete)
Comment 7 Dobrica Pavlinusic 2014-12-19 13:57:02 UTC
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.
Comment 8 Dobrica Pavlinusic 2014-12-22 14:09:12 UTC Comment hidden (obsolete)
Comment 9 paxed 2015-01-07 06:39:06 UTC
(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
Comment 10 Dobrica Pavlinusic 2015-01-08 11:46:42 UTC Comment hidden (obsolete)
Comment 11 Dobrica Pavlinusic 2015-01-08 11:47:09 UTC
(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.
Comment 12 Nick Clemens 2015-02-19 20:08:56 UTC Comment hidden (obsolete)
Comment 13 Nick Clemens 2015-02-19 20:09:06 UTC Comment hidden (obsolete)
Comment 14 Kyle M Hall 2015-02-20 14:04:42 UTC
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>
Comment 15 Kyle M Hall 2015-02-20 14:04:50 UTC
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>
Comment 16 Chris Nighswonger 2015-03-10 18:53:11 UTC
*** Bug 12553 has been marked as a duplicate of this bug. ***
Comment 17 Chris Nighswonger 2015-03-10 18:55:13 UTC
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.
Comment 18 Tomás Cohen Arazi 2015-03-11 17:09:41 UTC
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.
Comment 19 Chris Nighswonger 2015-03-13 15:52:37 UTC
(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.
Comment 20 Tomás Cohen Arazi 2015-03-13 21:59:10 UTC
Chris, tests on t/db_dependent are considered standard and are always run by the dev team and jenkins too, when pushed.
Comment 21 Tomás Cohen Arazi 2015-03-30 16:47:30 UTC
Patches pushed to master.

Thanks Dobrica!
Comment 22 Chris Cormack 2015-03-31 05:22:16 UTC
Pushed to 3.18.x will be in 3.18.6
Comment 23 David Cook 2015-09-21 06:03:15 UTC
Finally took the time to look at this one again... thanks indeed Dobrica!