Probably, but I'd like to do the job myself, and I had no idea of the best solution.
However, I think have just found a way to do that :-) :
- in preferences.pl, create a dropdown list with the name of actually existing templates, on the model of the existing "template" syspref (Use the "prog" theme on the staff interface.)
- it implies creating a new sub in Koha.pm, on the model of  sub getallthemes (used by "template" syspref), which will get the names of  files contained in acqui/pdfformat

I will open a enh for that and try to make the patch.

M. Saby



Marc Véron a écrit :
Mathieu,

I think this is worth to open a bug / enhancement.

Regards

Marc




Am 04.01.2013 10:17, schrieb Mathieu Saby:
Happy new year everybody!
Last month I asked a question regarding pdf templates for basketgroups,
but nobody answered.
So I reformulate :-)

Pdf templates are untranslatable, and the 2 defaut layouts is not
convenient at all for our library. So we want to define our own template.
I have done the job, but I can not activate it in system preferences
without removing some lines in /acqui/basketgroup.pl.
So, do you think it would be a good idea to give libraries the ability to
define their own templates? And what would be the best solution for that :
removing these lines in /acqui/basketgroup.pl, or creating a more flexible
security (I don't now how...)?


Regards,
M. Saby
Rennes 2 university


Mathieu Saby a écrit :
Hello

Our library has created a new templates for  exporting basketgroups in
pdf  (translated in french, and showing fields more usefull for us in
the tables than "layout2pages" and "layout3pages").
Of course, we could name this template "layout3pages", and replace the
standard template. But I think it would be "cleaner" to add this give
this new template a name of his own, so it won't be altered when our
Koha is updated.

The problem is some code in /acqui/basketgroup.pl prevents us to do
that. The only 2 valid templates for exporting basketgroups in pdf are
be "layout2pages" and "layout3pages". And we want to edit perl files as
less as possible.
http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=acqui/basketgroup.pl;h=6b7e5bf192a7b5cfa6761dc750bfc9fe5904bf60;hb=HEAD

188     if ($pdfformat eq 'pdfformat::layout3pages' || $pdfformat eq
'pdfformat::layout2pages'){
189         eval {
190         eval "require $pdfformat";
191             import $pdfformat;
192         };
193         if ($@){
194         }
195     }
196     else {
197         print $input->header; 198         print $input->start_html;
# FIXME Should do a nicer page
199         print "<h1>Invalid PDF Format set</h1>";
200         print "Please go to the systempreferences and set a valid
pdfformat";
201         exit;
202     }

This code was added by this Chris Cormack's commit :  "Bug 6679 Fix
scripts in admin & acqui to pass Perl::Critic"
http://git.koha-community.org/gitweb/?p=koha.git;a=commit;h=7cdea5de355e853f25300821cc641672443177de
added

So, here is my question :
Is this "security" in code really necessary ? And if it is, is there a
way to make it more flexible ?


Regards,

M. Saby
Rennes 2 University



_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/


-- 
Mathieu Saby
Service d'Informatique Documentaire
Service Commun de la Documentation
Université Rennes 2
Téléphone : 02 99 14 12 65
Courriel : mathieu.saby@univ-rennes2.fr