August 2008 - Koha-devel - lists.koha-community.org

koha-3.00.00 make fails
by Rick Welykochy 28 Dec '13

28 Dec '13

Hi all, I have downloaded http://download.koha.org/koha-3.00.00.tar.gz and began installing it on Debian/etch (in a Linux vserver environment). 0. FINE: cd koha-3.00.00 1. FINE: perl Makefile.PL 2. FAIL: make : : : Manifying blib/man3/C4::UploadedFile.3pm Manifying blib/man3/C4::BackgroundJob.3pm Manifying blib/man3/opac::opac-dictionary.3pm Manifying blib/man3/serials::member-search.3pm /usr/bin/perl "-Iblib/arch" "-Iblib/lib" fix-perl-path.PL blib /usr/bin/perl "-Iblib/arch" "-Iblib/lib" rewrite-config.PL blib/KOHA_CONF_DIR/koha-conf.xml Bad arg length for Socket::inet_ntoa, length is 0, should be 4 at rewrite-config.PL line 67. make: *** [blib/KOHA_CONF_DIR/koha-conf.xml] Error 255 Any ideas what went wrong and how to fix? Aside: there were a couple of other problems with this "out of the box" debian based install of Koha 3.0 which had to be fixed along the way, e.g. seven missing perl modules and libgd not found. I'll report on the entire process from unpacking to a running Koha/3.00.00 once I get to the end. cheers rickw -- ________________________________________________________________ Rick Welykochy || Praxis Services || Internet Driving Instructor The manual said Windows XP/SP2 or better so I installed Linux.

4 5

Can't call method "append_fields"
by constantine 13 Oct '09

13 Oct '09

Yes, the previous problem was solved, indeed... I do not understand why I have so many problems installing koha,.. maybe the last years I was too used to Joomla! installations :D So the challenging koha that its concept I so much admire and embrace makes me face another problem. Trying to add a MARC record, (I retrieved its data from a z30.50 server, but that does not matter, I think) and then I am getting an error page (http://localhost:8080/cgi-bin/koha/cataloguing/additem.pl) Its contents are: " Koha error The following fatal error has occurred: Can't call method "append_fields" on an undefined value at /usr/local/share/perl/5.10.0/MARC/File/SAX.pm line 95. at /usr/local/lib/perl/5.10.0/XML/LibXML/SAX.pm line 64 at /usr/local/share/perl/5.10.0/MARC/File/XML.pm line 443 Apache Server version: Apache/2.2.9 (Debian) Server built: Jun 21 2008 10:35:35 Koha 3.00.00.094 Koha DB 3.0000094 MySQL mysql Ver 14.12 Distrib 5.0.51a, for debian-linux-gnu (i486) using readline 5.2 OS Linux sangre 2.6.25.9xx6-costis07 #1 SMP PREEMPT Wed Jul 2 02:35:38 EEST 2008 i686 GNU/Linux Perl 5.010000 " The laste contens of /var/log/koha/koha-error_log are [...] [error] [...] [...] addbiblio.pl: INDEXING :orignew at /usr/share/koha/lib/C4/Biblio.pm line 2319., referer: http://localhost:8080/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&… [...] [error] [...] [...] addbiblio.pl: INDEXING :1 at /usr/share/koha/lib/C4/Biblio.pm line 2319., referer: http://localhost:8080/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&… [...] [error] [...] [...] addbiblio.pl: INDEXING :ocip at /usr/share/koha/lib/C4/Biblio.pm line 2319., referer: http://localhost:8080/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&… [...] [error] [...] [...] addbiblio.pl: INDEXING :20 at /usr/share/koha/lib/C4/Biblio.pm line 2319., referer: http://localhost:8080/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&… [...] [error] [...] [...] addbiblio.pl: INDEXING :y-gencatlg at /usr/share/koha/lib/C4/Biblio.pm line 2319., referer: http://localhost:8080/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&… [...] [error] [...] [...] addbiblio.pl: INDEXING :ddc at /usr/share/koha/lib/C4/Biblio.pm line 2319., referer: http://localhost:8080/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&… [...] [error] [...] [...] addbiblio.pl: INDEXING :SR at /usr/share/koha/lib/C4/Biblio.pm line 2319., referer: http://localhost:8080/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&… [...] [error] [...] [...] addbiblio.pl: INDEXING :pc15 2006-07-19 to SSCD at /usr/share/koha/lib/C4/Biblio.pm line 2319., referer: http://localhost:8080/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&… [...] [error] [...] [...] addbiblio.pl: INDEXING :jp00 2006-07-26 CIP recd at /usr/share/koha/lib/C4/Biblio.pm line 2319., referer: http://localhost:8080/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&… [...] [error] [...] [...] addbiblio.pl: INDEXING :jp20 2006-07-26 to subj at /usr/share/koha/lib/C4/Biblio.pm line 2319., referer: http://localhost:8080/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&… [...] [error] [...] [...] addbiblio.pl: INDEXING :jp03 2006-07-26 at /usr/share/koha/lib/C4/Biblio.pm line 2319., referer: http://localhost:8080/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&… [...] [error] [...] [...] addbiblio.pl: INDEXING :aa05 2006-07-27 at /usr/share/koha/lib/C4/Biblio.pm line 2319., referer: http://localhost:8080/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&… [...] [error] [...] [...] addbiblio.pl: INDEXING :1 at /usr/share/koha/lib/C4/Biblio.pm line 2319., referer: http://localhost:8080/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&… [...] [error] [...] [...] addbiblio.pl: INDEXING :1 at /usr/share/koha/lib/C4/Biblio.pm line 2319., referer: http://localhost:8080/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&… [...] [debug] mod_deflate.c(619): [...] Zlib: Compressed 37993 to 5966 : URL /cgi-bin/koha/cataloguing/additem.pl, referer: http://localhost:8080/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&… [...] [error] [...] [...] additem.pl: Can't call method "append_fields" on an undefined value at /usr/local/share/perl/5.10.0/MARC/File/SAX.pm line 95. at /usr/local/lib/perl/5.10.0/XML/LibXML/SAX.pm line 64, referer: http://localhost:8080/cgi-bin/koha/cataloguing/additem.pl?biblionumber=1&fr… [...] [error] [...] [...] additem.pl: at /usr/local/share/perl/5.10.0/MARC/File/XML.pm line 443, referer: http://localhost:8080/cgi-bin/koha/cataloguing/additem.pl?biblionumber=1&fr… What could I do to solve this problem? Tsardounis Constantine http://costis.name _______________________________________________ Koha-devel mailing list Koha-devel(a)nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

2 1

Authority in Koha 3 (English - Unimarc - NoZebra)
by Zeno Tajoli 27 Feb '09

27 Feb '09

Hi to all, I have found a but into installer data for Unimarc / English language. I'm using a NoZebra setting and I think this option is importan for this bug. The setup of Authority is based on the file installer/data/mysql/en/marcflavour/unimarc/mandatory/authorities_normal_unimarc.sql But this definition gives problems, see my e-mail "Problems on working with authority" in koha general list, 05 Jun 2008 09:14. A correct defintion is the frence definition. Probably the main problem is to insert authtypecode = '' into all records of tables auth_tag_structure and auth_subfield_structure. I think that the frence defintion could be good also for English Unimarc definition. My authority defintion (a transaltion of franch definition into english) is attached to this mail. Bye Zeno Tajoli CILEA - Segrate (MI) tajoliAT_SPAM_no_prendiATcilea.it (Indirizzo mascherato anti-spam; sostituisci quanto tra AT con @) _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

2 1

RFC: New System Preference to Determine which 'Types' and associated icons to display in advanced Search
by Joshua Ferraro 24 Oct '08

24 Oct '08

Hi all, It seems like every library has a different definition of what they want to display as 'Type' limits in the advanced search area. The API is currently flexible to support any defined indexes, but customizing this beyond the default itemtypes currently requires editing of the advsearch.tmpl templates -- not horrible, but still kinda annoying. I propose a new syspref that allows the user to specify either 'itemtypes' (default) or any codes from authorised_values to be the limits in place of itemtypes (so for example, ccode). This would allow every library to define their own authorised-values, and then use those as search limits in advsearch.tmpl, without any template modifications. It's a fairly trivial addition, and if we default to itemtypes, won't affect any existing Koha installations. Thoughts? Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

4 4

RFC 3.2 - general hold request changes
by Galen Charlton 22 Oct '08

22 Oct '08

Hi, I've already sent out a couple of RFCs about hold requests and friends, and will be sending out some more that relate to specific customer projects for LibLime, but I wanted to toss out a few ideas for general improvement. A large number of bugs have been turned up recently, most of which were postponed to 3.2, so I think the module is in need of some attention beyond the specific enhancements to be proposed. First, the reserves table needs at least one more column to handle item-level requests properly. Right now, reserves.itemnumber serves two purposes: (a) identifying the requested item if the hold is item-level and (b) identifying the item selected to fill a title-level request. This is a problem because it can be hard to distinguish between bib- and item-level requests, and impossible to do so once the request is filled and the item is waiting on the hold shelf. I propose to replace reserves.itemnumber with two columns: requested_itemnumber (NULL for bib-level requests, non-NULL otherwise) supplied_itemnumber (non-NULL once the request is filled) During a version upgrade, the value of reserves.itemnumber would be moved to requested_itemnumber if the priority > 0, and to supplied_itemnumber if the priority is 0. This is not a perfect heuristic, as a filled item-level request should set both columns, but I'm not sure we can do much better. Second, i think the reserveconstraints table needs to be removed. It appears to date to a time when a biblio could have more than one bilbioitem, but now that the relationship is one-to-one, it cannot serve its original purpose of limiting a request to only specific formats attached to a bib. Removing reserveconstraints would leave Koha supporting bib-level and item-level requests. If something in between bib-level and item-level is still needed, I suppose that it would have to be based on selecting which item types are suitable for filling a request on a given bib - for example, if the library attaches codex and audiobook items to the same bib and gives them different item types, reservecontraints (or its successor) might contain a list of item types. Third, since larger Koha libraries can have hold request queues a couple hundred patrons long or longer, I'm going to experiment with ways of managing the priority value so that it is possible to fill hold requests without having to touch every request in the queue, both to aid performance and to possibly avoid bugs where multiple requests for a given bib have the same priority. Fourth, I want to add an auto_increment reserve_id column to reserves to give us an opaque request ID to simplify FK relationships with tables such as the successor to reserveconstraints and additional tables that we may need as we extend the request system to handle recalls and other types of requests. Fifth, I want to do some work with C4::Reserves to cleanup the FIXMEs, improve the POD, and add functions to separate handling when items can be requested versus when they are available to fill hold requests. Regards, Galen -- Galen Charlton VP, Research & Development, LibLime galen.charlton(a)liblime.com p: 1-888-564-2457 x709 skype: gmcharlt

2 1

[RFC] Using Log4perl to extend and improve logging and debugging
by Andrew Moore 24 Sep '08

24 Sep '08

NOTE: This is an RFC patch. I don't expect it to be directly applied to your system, and please don't apply it to the main Koha repository! Here is an example of how we can use Log4perl to extend (and hopefully improve) our current logging methods. I'm hopeful that this does a few things for us: * This will help us separate our application errors from apache errors by letting us easily redirect our errors to other files. * This will help us debug things by letting us increase the level of warnings from some parts of the application while ignoring other parts. Since you can configure it to handle messages from different parts of your application differently, you can inspect only certain parts more closely. For instance, if you would like to log more information about all opac seraches in order to let you investigate that more closely, you can edit the configuration file to write all of those types of messages to a different file. * This will let us separate out debugging types of messages from error messages. I would like for Koha to tell me of rather important errors that should be investigated differently from how it tells me of debugging messages. You can configure really bad ones to go to email to your support team, and the rather mundane to be written to a file. * and maybe more! I've included a few examples in this patch. One is in C4::Members where I instantiate a Log4perl object and use it to record some information when a function is called. The object knows that it's in the C4::Members "category", so you can handle that information differently in the log4perl configuration file if you like. Another is a use from one of the opac scripts, opac-search.pl. It shows how you might log search queries to a separate place. Since we have a lot of calls to 'warn' scattered about our code, I incuded a __WARN__ handler in C4::Debug that catches all calls to warn and runs them through log4perl. Ideally, this is not necessary, but it's a way for us to transition to using log4perl from the state we're in now. Finally, I've included an example configuration file that shows how you might separate out messages from different parts of your application into different places. You can also send these messages through email, syslog, or other files. I'm interested in discussion about whether extending the way we do logging is necessary yet, and if so if this seems like a good direction. I know that this can be improved and doesn't solve all of our problems, so please let me know how you might improve this approach, or of another one you would prefer. --- C4/Debug.pm | 49 +++++++++++++++++++++++++++++++++++++++++++++---- C4/Members.pm | 13 +++++++++++++ log4perl.conf | 38 ++++++++++++++++++++++++++++++++++++++ opac/opac-search.pl | 5 +++++ 4 files changed, 101 insertions(+), 4 deletions(-) create mode 100644 log4perl.conf diff --git a/C4/Debug.pm b/C4/Debug.pm index 357764a..f54df40 100644 --- a/C4/Debug.pm +++ b/C4/Debug.pm @@ -21,6 +21,7 @@ use strict; use warnings; use Exporter; +use Log::Log4perl qw(:easy); # use CGI; use vars qw($VERSION @ISA @EXPORT $debug $cgi_debug); @@ -34,6 +35,22 @@ BEGIN { # %EXPORT_TAGS = ( all=>[qw($debug $cgi_debug)], ); } +=head2 BEGIN block for log4perl + +Log4perl is initialzed in a BEGIN block to make sure it's available +for other BEGIN blocks. + +Perhaps it's not necessary to have this in a BEGIN block in the final +code. + +The config file is hardcoded right now. That's not necessary. + +=cut + +BEGIN { + Log::Log4perl->init( '/home/acm/koha/dev/log4perl.conf' ); +} + BEGIN { # this stuff needs a begin block too, since dependencies might alter their compilations # for example, adding DataDumper @@ -65,10 +82,34 @@ BEGIN { } } -# sub import { -# print STDERR __PACKAGE__ . " (Debug) import @_\n"; -# C4::Debug->export_to_level(1, @_); -# } +=head2 __WARN__ handler + +this overrides calls to C<warn> so that they don't get written to +STDOUT, but instead get run through Log4perl + +=cut + +$SIG{__WARN__} = sub { + local $Log::Log4perl::caller_depth = $Log::Log4perl::caller_depth + 1; + my $logger = logger(); + $logger->warn( @_ ); +}; + +=head2 logger + +this function returns a logging object. It's not strictly necessary +since you can call many of the Log4perl methods as class methods just +fine. But, it shows one example of how we can set the logger category +to make the messages wind be treated differently based on whether they +are in the opac or staff interface. + +=cut + +sub logger { + my $class = shift; + my $log_category = shift || 'opac'; + my $logger = Log::Log4perl->get_logger($log_category); +} 1; __END__ diff --git a/C4/Members.pm b/C4/Members.pm index 7df9424..fde3001 100644 --- a/C4/Members.pm +++ b/C4/Members.pm @@ -31,6 +31,12 @@ use C4::Biblio; our ($VERSION,@ISA,@EXPORT,@EXPORT_OK,$debug); +# initialize a log4perl object to be used throughout this module. We +# give it a category of C4::Members. This lets us call methods on it +# with the logging separated out into different places from the rest +# of the application, if we want. +our $logger = Log::Log4perl->get_logger( __PACKAGE__ ); + BEGIN { $VERSION = 3.02; $debug = $ENV{DEBUG} || 0; @@ -2060,6 +2066,13 @@ sub DebarMember { return unless defined $borrowernumber; return unless $borrowernumber =~ /^\d+$/; + # Here's an example of using the logger object. You can call + # 'debug' 'info', 'warn', 'error', or 'fatal' on it to send + # messages with different levels of priority. They may get treated + # differently (or ignored entirely) depending on your + # configuration. + $logger->info( "debarring borrower $borrowernumber" ); + return ModMember( borrowernumber => $borrowernumber, debarred => 1 ); diff --git a/log4perl.conf b/log4perl.conf new file mode 100644 index 0000000..de90960 --- /dev/null +++ b/log4perl.conf @@ -0,0 +1,38 @@ +# Where do we write the log files? +# Eventually, this will use a __VARIABLE__ so that the installer writes the right value in at install time. +log_file_root = /home/acm/koha/run/var/log + +# by default all log information can go to a default file, but only at ERROR level (or more severe) +log4perl.logger = ERROR, FileAppenderDefault + +log4perl.appender.FileAppenderDefault = Log::Log4perl::Appender::File +log4perl.appender.FileAppenderDefault.filename = ${log_file_root}/koha.log +log4perl.appender.FileAppenderDefault.layout = Log::Log4perl::Layout::SimpleLayout + +# opac activity can be directed to a separate file +log4perl.logger.opac = WARN, FileAppenderOpac + +log4perl.appender.FileAppenderOpac = Log::Log4perl::Appender::File +log4perl.appender.FileAppenderOpac.filename = ${log_file_root}/koha-opac.log +log4perl.appender.FileAppenderOpac.layout = Log::Log4perl::Layout::SimpleLayout + +# staff interface activity +log4perl.logger.staff = WARN, FileAppenderStaff + +log4perl.appender.FileAppenderStaff = Log::Log4perl::Appender::File +log4perl.appender.FileAppenderStaff.filename = ${log_file_root}/koha-staff.log +log4perl.appender.FileAppenderStaff.layout = Log::Log4perl::Layout::SimpleLayout + +# cronjobs and other activity may be directed to another file or handler +log4perl.logger.cron = WARN, FileAppenderCron + +log4perl.appender.FileAppenderCron = Log::Log4perl::Appender::File +log4perl.appender.FileAppenderCron.filename = ${log_file_root}/koha-cron.log +log4perl.appender.FileAppenderCron.layout = Log::Log4perl::Layout::SimpleLayout + +# In order to facilitate debugging OPAC search, perhaps we want log them at DEBUG level to the same OPAC file. +log4perl.logger.opac.search = DEBUG, FileAppenderOpac + +# Or, maybe right now we don't want to log any search strings because they're annoying while we're researching something else. +# log4perl.logger.opac.search = OFF, FileAppenderOpac + diff --git a/opac/opac-search.pl b/opac/opac-search.pl index 5f50861..2aa0be8 100755 --- a/opac/opac-search.pl +++ b/opac/opac-search.pl @@ -45,6 +45,11 @@ elsif ($build_grouped_results) { } elsif ((@params>=1) || ($cgi->param("q")) || ($cgi->param('multibranchlimit')) || ($cgi->param('limit-yr')) ) { $template_name = 'opac-results.tmpl'; + + # In this example, we're trying to log each search query. Since I want to be + # able to separate them apart from other logging, let's give them a different log + # category. And, it's pretty verbose, so let's send them at the "debug" level. + C4::Debug->logger('opac.search')->debug( 'searched for: ' . $cgi->param('q') ); } else { $template_name = 'opac-advsearch.tmpl'; -- 1.5.6

3 2

RFC 3.2: Autogeneration of Koha UML diagrams
by Zeno Tajoli 03 Sep '08

03 Sep '08

Hi to all, from first day of October 2008 CILEA is going to support a project about Koha as student stage (followd by me). We want to improve tecnical documentation about Koha 3.0 (I hope to have a stable release for october !!). Starting from perl scripts avaible from internet we want to develop a script that read Koha API (C4 dir) and write a .xmi file with an UML rappresentation of classes, methods and usage of methods. In fact a work like this is possible only if API are written in a precise standard of coding. It thimk it s , as I know. But this is also a good check. We will report all problems we found, to be fixed in 3.2 We also write complete E-R diagrams for Koha DB and a specific document for every table But now the .xmi file in fact needs to be sligthy different for every UML tool. We can work with two Open source tool, ArgoUML and Umbrello We can usa also Rational Rose (the biggest commercial tool for UML). Which tool do you prefer ? If you think it is a useful project, I will insert it into RFCs for Koha 3.2 <http://wiki.koha.org/doku.php?id=en:development:rfcs3.2> Bye Zeno Tajoli CILEA - Segrate (MI) tajoliAT_SPAM_no_prendiATcilea.it (Indirizzo mascherato anti-spam; sostituisci quanto tra AT con @)

4 5

RFC: Advanced patron search
by Danny Bouman 02 Sep '08

02 Sep '08

"Problem The ability is needed to search for patrons on many different fields, including email address, street address, phone number, etc. Using additional patron attributes is not a viable solution as it would require a tremendous amount of duplicate data on all fields that would need to be searchable. Possible Solution #1 Create a standard search API that functions for both circulation and patron searches and supports the ability to search on many different fields. Possible Solution #2 Create a member search API that supports the ability to search for patrons on many different fields. Technical Notes System preference should exist for what patron fields are able to be searchedWhen a Staff member clicks on the Patron menu item, they should immediately be taken to the advanced search screen, which could exist below the browse by last name. This display would be in a similar format to what Staff see when they click on the Search menu item.Patron Attribute types that are able to be searched should appear in the advanced search. http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:rfc32_advancedpatro… Any thoughts, questions, or comments? -- Danny Bouman Web Programmer Howard County Central Library 10375 Little Patuxent Parkway Columbia, MD 21044 410.313.7924

3 3

RFC 3.2 - turn on warnings
by Galen Charlton 30 Aug '08

30 Aug '08

Hi, Perl's warnings pragma is the cheapest way to find bugs. We already use the strict pragma; now it's time to add warnings. More importantly, it's time to review the messages produced by the warnings pragma and fix the underlying issues. To reiterate, this RFC has two goals: turning on warnings, and fixing all warnings thus reported. Doing the first without the second will simply cause Apache logs to overflow. Ideally, all Perl scripts and modules should have warnings enabled by the time 3.2 is released. I propose the following steps to implement this: 1. Update the coding guidelines to require 'use strict' and 'use warnings'. 2. For any new scripts and modules, require 'use warnings'. Since Koha (per Makefile.PL) requires at least Perl 5.6.1, the 'use warnings' pragma should be used instead of -w. 3. Systematically go through and turn on warnings for each script and module. 4. Unsystematically turn on warnings. I.e., whenever you patch a particular script, consider following up with a separate patch to turn on warnings. I suggest a separate patch because turning on warnings is not enough; you should run the script through its paces and fix any problems reported by the warnings pragma. For modules in C4, note that this can be a big commitment: turning on warnings means testing every function and method. 5. Create a standing blocker bug for 3.2 for adding "use warnings". 6. "no warnings" should not be used absent a detailed comment explaining why warnings should be turned off within a block and why it is not possible to change the code to avoid the warning. It _might_ be acceptable for temporary use while turning on warnings in a big module This RFC can also be found at http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:rfc32_turn_on_warni… Regards, Galen -- Galen Charlton VP, Research & Development, LibLime galen.charlton(a)liblime.com p: 1-888-564-2457 x709 skype: gmcharlt

6 14

RFC 3.2 : guided reports improved
by Paul POULAIN 30 Aug '08

30 Aug '08

(http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:rfc32_guided_reports) Guided reports are great. However, they are fully hardcoded SQL atm. There's no possibilities to have parameters that are fixed at run time. That would be usefull, for example, when you want to build a report that runs between a date range, or on a given branch or itemtype. for example, a tool to let a given branch see what they added in the catalogue could be : SELECT biblio,author FROM biblio LEFT JOIN items USING(biblionumber) WHERE items.homebranch=XXX This RFC suggest to add some improvements to be able to specify XXX at runtime. - A simple solution could be to have a specific syntax to say "enter value here". For example : ??? - A better sotution could be to have the syntax + a label to display to the patron. For example : ???Enter branch code??? that would display "Enter branch code : _______" in the <form> - The best solution would be to have a list where applicable (branch, itemtype...). The 2 first are easy to code, the 3rd could be tricky. but undoubtfully usefull ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08

7 10