Bug 4188 - Basketgroup print fails to generate a file
Summary: Basketgroup print fails to generate a file
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Acquisitions (show other bugs)
Version: rel_3_2
Hardware: PC All
: P1 - high blocker (vote)
Assignee: Galen Charlton
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-15 09:23 UTC by Colin Campbell
Modified: 2019-06-27 09:24 UTC (History)
4 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 01:24:10 UTC


---- Reported by colin.campbell@ptfs-europe.com 2010-02-15 09:23:29 ----

Trying to print a basket group fails silently. The pdf download box appears with an invalid filw name ( .pdf) . The following errors can be seen in the log

[Sun Feb 14 19:45:39 2010] basketgroup.pl: Using a hash as a reference is deprecated at /home/koha/kohaclone/acqui/basketgroup.pl line 240.
[Sun Feb 14 19:45:39 2010] basketgroup.pl: 1 at /home/koha/kohaclone/acqui/basketgroup.pl line 187.
[Sun Feb 14 19:45:39 2010] basketgroup.pl: GLOB(0xac8c920) not a PDF file version 1.x at /usr/share/perl5/PDF/API2/Basic/PDF/File.pm line 302.



---- Additional Comments From colin.campbell@ptfs-europe.com 2010-02-15 09:28:04 ----

Bug also reported as part of http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3622 with screenshot



---- Additional Comments From nengard@gmail.com 2010-02-15 12:20:11 ----

*** http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3915 has been marked as a duplicate of this bug. ***



---- Additional Comments From frederic@tamil.fr 2010-04-18 09:34:52 ----

Taking a look at the code, it appears that the 'printpdf' function, located in acqui/pdfformats/layout2pages.pm module, expect to have a 'OrderPdfTemplate' syspref containing a full PDF template to based on generated PDF file. This PDF template exists as a file in the module directory: layout2pages.pdf. If its content is copied into 'OrderPdfTemplate' syspref, it works!



---- Additional Comments From frederic@tamil.fr 2010-04-18 09:54:28 ----

A suggested patch:

http://lists.koha.org/pipermail/koha-patches/2010-April/006036.html



---- Additional Comments From gmcharlt@gmail.com 2010-04-30 12:40:04 ----

I repeat the request I made on 19 April 2010 via a koha-patches email for somebody from BibLibre to comment on this bug and Frédéric's proposed patch.



---- Additional Comments From jeanandre.santoni@biblibre.com 2010-04-30 13:41:02 ----

You have to upload the PDF in the OrderPdfTemplate syspref. This syspref is of the type 'upload', it can contain the whole pdf file, base64 encoded in a BLOB.

This way, users can customize their PDF (as long as they respect the differents layouts proposed by Koha)

Maybe patches are incomplete, or some of them have been lost in the trip?

I know that this sort of syspref is a bad idea, but I had no other : Paul asked to to NEVER let users upload real files on the server. I never understood why. In the PHP world we do it all the time (see Drupal) for exemple. Maybe because the security issues aren't the same when running as CGI or as apache module?

...but I think we should not loose this feature wich might be usefull for some people. It just need to be documented. What do you think?



---- Additional Comments From gmcharlt@gmail.com 2010-05-04 16:05:25 ----

(In reply to comment #6)
> You have to upload the PDF in the OrderPdfTemplate syspref. This syspref is of
> the type 'upload', it can contain the whole pdf file, base64 encoded in a BLOB.
> 
> This way, users can customize their PDF (as long as they respect the differents
> layouts proposed by Koha)
> 
> Maybe patches are incomplete, or some of them have been lost in the trip?
> 
> I know that this sort of syspref is a bad idea, but I had no other : Paul asked
> to to NEVER let users upload real files on the server. I never understood why.
> In the PHP world we do it all the time (see Drupal) for exemple. Maybe because
> the security issues aren't the same when running as CGI or as apache module?
> 
> ...but I think we should not loose this feature wich might be usefull for some
> people. It just need to be documented. What do you think?
> 

Thanks for the explanation.  Unfortunately, the ability to upload PDF templates, while something I am OK with in principle, has a severe limitation: layout2pages.pm and layout3pages.pm currently hardcode absolute positions on the template to place text from the order.  That means that only very trivial changes to the templates could be made without forcing the user to edit the Perl files.  If you make them do that, which would be a server-based operation, they can just as well upload new PDF templates.

For 3.2, I will push a version of Frédéric's patch and hide the OrderPdfTemplate syspref.  It can be revived in 3.4, hopefully with a better templating engine such as PDF::Reuse underneath so that we can also get rid of the hard-coded position in layout[23]pages.pm.



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:24 UTC  ---

This bug was previously known as _bug_ 4188 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4188
This bug depended on bug(s) 3985.

Actual time not defined. Setting to 0.0
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.
CC member jeanandre.santoni@biblibre.com does not have an account here

Comment 1 Chris Cormack 2010-06-16 02:44:03 UTC
Has this patch been pushed? Can we close this, or reassign to rel_3_4 ?
Comment 2 Frédéric Demians 2010-06-16 05:14:07 UTC
> Has this patch been pushed? Can we close this, or reassign to rel_3_4 ?

No, it hasn't.
Comment 3 Galen Charlton 2010-07-02 12:51:07 UTC
Pushed series of patches.  Please test and close; if the ability to upload PDF templates to the OrderPdfTemplate syspref is still desired, that can be the subject of a new bug.
Comment 4 Frédéric Demians 2010-07-02 13:19:19 UTC
It works now as expected with HEAD code.
Comment 5 Nicole C. Engard 2010-07-03 13:22:22 UTC
For me in Firefox on Mac it saved the file as .pdf - no first part which made it so that I had to manually edit the file name to make it open.  So it needs a filename and then it's perfect!
Comment 6 Frédéric Demians 2010-07-03 14:28:44 UTC
> For me in Firefox on Mac it saved the file as .pdf - no first part which made
> it so that I had to manually edit the file name to make it open.  So it needs a
> filename and then it's perfect!

I can see your issue. It occurs when basket group has no name. I will send a patch.
Comment 7 Frédéric Demians 2010-07-03 14:34:22 UTC
A solution for Nicole issue:

http://lists.koha-community.org/pipermail/koha-patches/2010-July/012222.html
Comment 8 Galen Charlton 2010-07-06 12:21:24 UTC
Pushed patch to handle case where basket group has no name.  Please test and close.
Comment 9 MJ Ray (software.coop) 2010-07-07 19:17:06 UTC
Updating version as described in http://wiki.koha-community.org/wiki/General_IRC_Meeting,_7_July_2010
Comment 10 Nicole C. Engard 2010-07-07 22:40:18 UTC
appears to work now