Bug 6369

Summary:	Formatting problems on some items when printing an order form (PDF).
Product:	Koha	Reporter:	Frédérick Capovilla <fcapovilla>
Component:	Acquisitions	Assignee:	Frédérick Capovilla <fcapovilla>
Status:	CLOSED FIXED	QA Contact:	Bugs List <koha-bugs>
Severity:	normal
Priority:	PATCH-Sent (DO NOT USE)	CC:	chris, f.demians, paul.poulain
Version:	rel_3_2
Hardware:	All
OS:	All
Change sponsored?:	---	Patch complexity:	---
Documentation contact:		Documentation submission:
Text to go in the release notes:		Version(s) released in:
Circulation function:
Bug Depends on:	7138
Bug Blocks:
Attachments:	Correct a formatting problem in the pdf generation of basketgroup.pl proposed patch (passed QA)

Description Frédérick Capovilla 2011-05-18 20:38:21 UTC Comment hidden (obsolete)

Created attachment 4174 [details] [review]
Correct a formatting problem in the pdf generation of basketgroup.pl

In /acqui/basketgroup.pl :
When printing an order form for a basketgroup, some items appeared incorrectly in the resulting pdf file.

The formatting problem happens if $ord->{itemtype} has a value, but $bib->{itemtype} does not.

Patch attached to correct this problem.

Comment 1 Frédérick Capovilla 2011-05-18 20:47:44 UTC

More details :
The formatting problem happens when a biblioitem has an itemtype that doesn't exist in the itemtypes table.

Comment 2 Chris Cormack 2011-06-10 03:28:20 UTC

Frederic (without a k :)) Did you miss sending or attaching the signed off patch?

Comment 3 Paul Poulain 2011-08-11 08:56:22 UTC

Created attachment 4960 [details] [review]
proposed patch (passed QA)

QA comment

* seems Frédéric D. signed-off patch has been lost in limbo
* tested the patch, works as expected & fixes the problem

Marking "passed QA"

Comment 4 Chris Cormack 2011-08-12 01:46:50 UTC

Pushed, please test

Comment 5 Katrin Fischer 2011-11-02 22:00:17 UTC

At the moment pdf printing seems to be broken for me, so I can't close this bug yet. The pdf files I create have following text inside:

<h1>Software error:</h1>
<pre>Undefined subroutine &amp;main::printpdf called at /home/katrin/kohaclone/acqui/basketgroup.pl line 275.
</pre>

Investigating...

Comment 6 Frédérick Capovilla 2011-11-04 14:04:49 UTC

(In reply to comment #5)
> At the moment pdf printing seems to be broken for me, so I can't close this bug
> yet. The pdf files I create have following text inside:
> 
> <h1>Software error:</h1>
> <pre>Undefined subroutine &amp;main::printpdf called at
> /home/katrin/kohaclone/acqui/basketgroup.pl line 275.
> </pre>
> 
> Investigating...

The problem appeared in 3.6. See Bug 7138 .

Comment 7 Paul Poulain 2011-11-09 14:54:22 UTC

The line 275 shows :
    my $pdf = printpdf($basketgroup, $bookseller, $baskets, \%orders, $bookseller->{gstrate} // C4::Context->preference("gist")) || die "pdf generation failed";


printpdf is supposed to be loaded at line 190 :
    my $pdfformat = C4::Context->preference("OrderPdfFormat");
    if ($pdfformat eq 'pdfformat::layout3pages' || $pdfformat eq 'pdfformat::layout2pages'){
	eval {
	    require $pdfformat;
	    import $pdfformat;
	};
So, what does OrderPdfFormat contains ? If it's not pdfformat::layout3pages or pdfformat::layout2pages, nothing is "require-ed", and printpdf fails

Comment 8 Katrin Fischer 2011-11-09 15:28:47 UTC

Paul, plz also check 7138. I have tested entering nothing or a wrong value in the system preference. The browser shows a nice error message in this case now.

Comment 9 Paul Poulain 2011-11-09 16:19:43 UTC

yikes. The "depends on" link is really not visible enough, I missed it (once again), thx kf. 

patch 7138 pushed, this one can be tested now I think

Comment 10 Katrin Fischer 2011-11-30 06:56:13 UTC

I set biblioitems.itype to an invalid value. PDF still printing correctly.