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

How about a different way of handling database updates
by Michael Hafen 18 Feb '10

18 Feb '10

Database updates using the updatedatabase.pl script. I'm thinking there could be a better way, both for developers and the release maintainers. The problem is that we have a sequential number controlling the updates. This is working now, but I think there could be a better way. The current method is simple, it has that benefit. On the other hand it makes things more complex for the release maintainer to make sure the sequence is right. It's also more complex for the developers to coordinate who will use what number. My idea is to use a string for the update instead of a number. It will mean adding a table to the database to track update strings that have been applied. This way each developer, or company, uses their own string to distinguish updates. Also, in order to keep the table from being huge, the release maintainer will occasionally announce a database revision. We will keep the number to effectively federate the updates. Within each revision there will be any number of update strings. With each new revision it is assumed that the updates from the previous version are applied, so the database table is emptied. There will be some added complexity when when there is a revision. The developers who are working on update code will have to move their in the updatedatabase.pl file into the section for the new revision. The added benefit of this method is that developers, and companies, can have a database update easily without worrying about it getting into the official code repositories. The change is kept in the developers own branch, with it's unique update string, while others that are accepted into the official code are also there. Does that make sense? Have I described it well enough? Is anyone interested in this idea? I've been thinking about it, and the changes to the database update process should be minimal. There will be significant changes, but not many of them. There will have to be a sub added to check if an update string is in the database. And a sub to add the update string to the tracking table in the database. And the revision update sub will have to be expanded to empty that table. I think that would be the extent of the changes. Comments please. -- Michael Hafen Systems Analyst and Programmer Washington County School District Utah, USA for Koha checkout http://development.washk12.org/gitweb/ or git://development.washk12.org/koha

11 26

koha 3.0.5 + print slip problem
by Zico 17 Feb '10

17 Feb '10

Hi, i have been trying to print slip from Koha 3.0.5. I am using Star TSP650. But, when the print occurs, it takes a 11.5 inch/A4 size slip; whereas the datas are very little there in that page. I tried to find the page setup from Firefox; but it hasn`t change anything. -- Best, Zico

3 3

Change requested: XSLT syspref changes in 3.0.x
by Galen Charlton 17 Feb '10

17 Feb '10

Hi, I would like to request that the following 3.0.x commits be reverted or modified before the release of 3.0.6. 4b04de209aa25816f5d97c05ce71ea9619027484 3057a7afb98c9224d3fd987131ae88956eb513d3 The upshot of these changes are that XSLTDetailsDisplay and XSLTResultsDisplay were changed from a Boolean to a free text field containing the full path to the desired XSLT stylesheets. Unfortunately, this has a defect that I would really prefer not get propagated, and I would not have accepted this change for HEAD as is. Specifically, unlike every other syspref that specifies an override of a template or CSS file, the proposed change requires the operator to know and enter the server path of the stylesheet, *including* the language directory (assuming that the operator is specifying a local stylesheet). For example: ../koha-tmpl/opac-tmpl/prog/en/xslt/MARC21slim2OPACDetail.xsl Besides forcing the operator to get the path right (and OPAC results and/or details display breaks if the operator gets it wrong), which no other syspref requires, it prevents a multi-lingual OPAC from being able to use a different stylesheet for each translation it uses. Local template and XSL files referred to by a syspreef should always be presented to the operator relative to the translation, i.e., a plain 'MARC21slim2OPACDetail.xsl' instead of '../koha-tmpl/opac-tmpl/prog/en/xslt/MARC21slim2OPACDetail.xsl', with code to select the appropriate translation. Furthermore, it should degrade more gracefully if the XSLT file specified in the syspref doesn't exist. In the short term, I would like to see one of the following happen: [1] The changes get reverted in 3.0.x, leaving the sysprefs as Boolean and allowing this enhancement to be dealt with in HEAD for 3.2. [2] The changes get improved so that there is a fallback and the syspref will respect the translation system. Regards, Galen -- Galen Charlton Koha 3.2 Release Manager gmcharlt(a)gmail.com

1 0

Measuring Koha resource usage
by Charl 17 Feb '10

17 Feb '10

Is there a specific tool available to check/record Koha's usage on a server? If not, which processes should be checked/measured? Thanks

1 0

Hourly loans
by Oscar Gaona 17 Feb '10

17 Feb '10

Hi, again We need to establish a hourly loans policy running Koha. I know it is a piece of the plan for Koha 2, but I ask: is it possible to reconfigure any stable version for doing that rule. Thanks for any idea. Regards. Oscar.

2 1

Koha, AIX, Oracle
by Oscar Gaona 17 Feb '10

17 Feb '10

Hi all Is there any experience running Koha, AIX and / or Oracle? Which could be 'the way' to get it? Thanks in advance. Oscar

2 1

Enable GranularPermissions by default
by Galen Charlton 16 Feb '10

16 Feb '10

Hi, I would like to have the default value of GranularPermissions be ON for 3.2, and push a DBrev to turn it on for existing installations. Particularly with new_acq, I think we've reached to point to do this. Any objections? Regards, Galen -- Galen Charlton gmcharlt(a)gmail.com

5 4

New version of Yaz
by Chadwick, John, DCA 16 Feb '10

16 Feb '10

I just noticed that there is a new version of Yaz. We have gone from 3.0.x to 4.0.x. Can anyone share what may have been fixed with this upgrade? Thanks, John +----------------------------------------------------------------------- -----+ John Chadwick, Ed.D. Information Technology Manager New Mexico State Library 1209 Camino Carlos Rey Santa Fe, NM 87507 Phone: 505-476-9740 Cell: 505-629-8116 Fax: 505-476-9761 john.chadwick(a)state.nm.us http://www.nmstatelibrary.org Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. ______________________________________________________________________ Confidentiality Notice: This e-mail,including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review,use,disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. This email has been scanned using Webroot Email Security. ______________________________________________________________________

5 5

Extra biblio information in the Normal view
by Toni Rosa 16 Feb '10

16 Feb '10

Hello, We are using Koha 3.00.04. In the intranet "normal" view of a biblio we needed to differentiate the additional authors whether they are personal, corporate or conference ones (Marc 700, 710 or 711). To achieve this I had to include this information in the structure returned by the method "GetMarcAuthors" of the file lib/C4/Biblio.pm. Line 1472: push @subfields_loop, {* tag=> $field->tag() *,code => $subfieldcode, value => $value, link_loop => \@this_link_loop, separator => $separator} unless ($authors_subfield->[0] eq '9' ); Then in the template file (catalogue/detail.tmpl) I could add something like this: <TMPL_IF EXPR="tag == 700">Personal: <TMPL_IF EXPR="tag == 710">Organization: <TMPL_IF EXPR="tag == 711"Conference: Type "":    Is it okey or Is there an easier and not that intrusive way of doing it? Regards, Toni

2 3

perltidy
by Colin Campbell 15 Feb '10

15 Feb '10

There was a little bit of discussion on irc a few days back about perltidy and using it to get a bit of consistency in the formatting of the codebase. (consistency is good it means the surproses are more likely to be good than unpleasant). For those of you unfamiliar with perltidy its the program in the perl module Perl::Tidy which if you run it on a perl script produces a version consistently formatted according to irs rules. For more info see the docs at http://perltidy.sourceforge.net also man perltidy and perldoc Perl::Tidy The default rules in perltidy are an expansion of those in the perl style guide (perldoc perlstyle). Koha has its own set of recommendations, for the most part these are the defaults with perltidy. The uncommented lines in xt/perltidyrc show where we've overridden the defaults, they are: cuddled_else opening-brace-always-on-tight (a logical extension of cuddling your else) paren-tightness=1 (uncommented as if a non-default but is the perltidy default) vertical-tightness ( see the examples in Perl Best Practices for a reason for this) maximum-line-length=178 I would suggest that the maximum-line-length be reduced ( The default value is 80), my reasoning is this: although we all have editors and terminals that handle long lines, we actually like to use that screen estate to see more than one file, so that letting the code wander off to the right makes it easier to miss important clues when reading it. Especially when using tools like vimdiff, git diff, git blame etc. I feel if you have a line like: ($lots, $of, $returns) = call_subroutine( $with, $more, $arguments, $than, $it $should @have) if ($i_want_to_hide_my_conditional && $x == $y); a few judiciously placed new lines make it more readable and more maintainable, and with a long line length they disappear. Also a quick unscientific scan through the existing codebase a few days back revealed 96.96% of existing lines are 80 characters or less ( 99.7% are less than 100) so that perltidying with a long line length may have a detrimental effect in some cases. Also it seems we are by default using shorter lines. I think we should resolve this before considering any cleanup operations. Finally a tip. I found this in the book Perl Hacks with these two vim mappings: map ,pt <ESC>:%! perltidy<CR> map ,ptv <ESC>: '<,'>! perltidy<CR> I can use the commands ,pt and ,ptv in vim tp perltidy the file, or a region of the file within the editor. The latter is esprcially handy if I've added a few lines to a file and I want them formatted consistently but I don't want to obscure the files revision history by cleaning up code I've not touched. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campbell(a)ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com

3 2