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

Koha 3.10 : git branch created
by Paul Poulain 01 Nov '12

01 Nov '12

Hello koha-devel, The branch 3.10.x has been created and the 3.12 Release Manager has endorsed the master branch. As Release Manager for 3.10 that will be released in 3 weeks, I'm responsible for the 3.10.x branch. Depending on what you want to work with, if you have a git setup, you can/must do * git checkout -b 3.10.x origin/3.10.x => use 3.10 * git checkout origin/master => use master (that will be 3.12 in 6+ months) We will follow the following rules : * Jared pushes first on master branch * I then push on 3.10 branch It mean Jared won't probably push anything large before the 3.10.0 release, and I'll point him the bugfixes that need to be "promoted" to "patch pushed" -- Paul POULAIN - BibLibre http://www.biblibre.com Free & Open Source Softwares for libraries Koha, Drupal, Piwik, Jasper

1 0

Batch item modification problems in 3.8.x?
by Tomas Cohen Arazi 01 Nov '12

01 Nov '12

Has anyone noticed a bug on batch item updates? Two different librarians reported that bulk changing the itemtype (provided a file with the barcodes) results in NULL values for the rest of the items on those biblios. If someone had that problem just let me know. I'll try to investigate i bit tomorrow. Regards To+

1 0

100$a mapping fixed
by Paul 01 Nov '12

01 Nov '12

I wrote earlier: "All that remains is to work out why our cataloguers cannot get the 100$a into the correct column" but have now found a "fix" that worked for us (I am *not* saying that this might work under other circumstances). From <http://koha-community.org/faqs/relationship-koha-marc-mapping-marc-bibliogr…>: "Mapping can be defined through 'MARC Bibliographic Frameworks' OR 'Koha to MARC Mapping'. 'Koha to MARC Mapping' is just a shortcut to speed up linkage. If you change a mapping in one of these modules, the mapping will change in the other as well. (In other words, the two modules 'overwrite' each other in order to prevent conflicts from existing in Koha). " After upgrade to 3.8.5, both the frameworks and the mapping showed "Author ==> 100$a". On the sandbox yesterday, I deleted all the biblio (not biblioitems nor items) 'Mappings' late in the day and closed the machine down. I restored them (same values as before, only framework code, timestamp and datecreated blank since 3.6.1) and rebooted. Bingo! Cataloguing now fills biblio.author and the XML counterpart. Just done the same on the production box (including two reboots, first time since the upgrade to 3.8.5) and it is also fixed. I have no clue what went wrong; whether it's something corrupt in our Koha db, whether it could be related to Koha, dependencies or other combinations of software (that box runs memcached, several other cgi web-based modules, other db's on MySQL, and SendMail) or whatever. Serendipity is ... Best regards, Paul

2 1

Re: [Koha-devel] Losing biblio.author in 3.8.5
by Paul 01 Nov '12

01 Nov '12

At 02:27 PM 10/31/2012 -0600, Mike Hafen wrote: >Would an SQL Update statement be more effective here? Like: >UPDATE biblio SET author = >ExtractValue(marcxml,'//datafield[@tag="100"]/subfield[@code>="a"]') WHERE >author IS NULL Many thanks for the suggestion, but I ran into problems -- I think it's to do with mixing a straightforward 'table/column' as in biblio.author with an 'ExtractValue' from a different table. Here's your suggestion: mysql> UPDATE biblio SET author = ExtractValue(marcxml,'//datafield[@tag="100"]/subfield[@code>="a"]') WHERE author IS NULL; ERROR 1054 (42S22): Unknown column 'marcxml' in 'field list' So I tried a second FROM to point to the 'table/column' with marcxml FROM biblioitems: mysql> UPDATE biblio SET author = ExtractValue(marcxml,'//datafield[@tag="100"]/subfield[@code>="a"]') FROM biblioitems WHERE author IS NULL; ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'FROM biblioitems WHERE author IS NULL' at line 1 No joy; so bracket the 'ExtractValue' with the table in front of it: mysql> UPDATE biblio SET author = (biblioitems(ExtractValue(marcxml,'//datafield[@tag="100"]/subfield[@code>="a"]')) WHERE author IS NULL; ERROR 1305 (42000): FUNCTION koha384.biblioitems does not exist MySQL reads that as a FUNCTION, so put biblioitems. inside the bracket: mysql> UPDATE biblio SET author = ExtractValue(biblioitems.marcxml,'//datafield[@tag="100"]/subfield[@code>="a"]') WHERE author IS NULL; ERROR 1054 (42S22): Unknown column 'biblioitems.marcxml' in 'field list' MySQL is really touchy ;={ I hate bothering you, but do you have thoughts on this? Thanks - Paul >On Wed, Oct 31, 2012 at 1:00 PM, Paul ><<mailto:paul.a@aandc.org>paul.a(a)aandc.org> wrote: >At 08:09 PM 10/29/2012 +0100, you wrote: >Hi Paul, > >[snip] > >For your reports you always have the option to query the MARCXML data >directly, nothing should be lost. > > >I agree -- in fact for staff, I've already written a new report replacing >biblio.author with >ExtractValue(marcxml,'//datafield[@tag="100"]/subfield[@code>="a"]') and >it works perfectly. > >But this doesn't "correct" the MySQL db. Where/why on earth has it gone >wrong, and how to correct it? > > >Could some kind soul with knowledge of using XML in MySQL assist? > >I'm trying to copy the XML 100$a to biblio.author where this latter is >NULL, but: > >mysql> INSERT INTO biblio (biblio.author) > -> SELECT > ExtractValue(marcxml,'//datafield[@tag="100"]/subfield[@code>="a"]') FROM > biblioitems > -> WHERE biblio.author IS NULL; >ERROR 1054 (42S22): Unknown column 'biblio.author' in 'where clause' > >so I tried to be more explicit for biblio.author and now the XML has an error > >mysql> INSERT INTO biblio (biblio.author) > -> SELECT author FROM biblio, > ExtractValue(marcxml,'//datafield[@tag="100"]/subfield[@code>="a"]') FROM > biblioitems > -> WHERE biblio.author IS NULL; >ERROR 1064 (42000): You have an error in your SQL syntax; check the manual >that corresponds to your MySQL server version for the right syntax to use >near '(marcxml,'//datafield[@tag="100"]/subfield[@code>="a"]') FROM biblioitems >WHERE' at line 2 > >I have tried various combinations of LEFT|RIGHT JOIN biblio ON ( >biblioitems.biblionumber = biblio.biblionumber) but with no success so far. > > >Thanks and regards -- Paul > > > > > > > >Hope that helps, >Katrin > >-----Ursprüngliche Nachricht----- >Von: ><mailto:koha-devel-bounces@lists.koha-community.org>koha-devel-bounces(a)lists.koha-community.org >im Auftrag von Paul >Gesendet: Mo 29.10.2012 19:55 >An: ><mailto:koha-devel@lists.koha-community.org>koha-devel(a)lists.koha-community.org > >Betreff: [Koha-devel] Losing biblio.author in 3.8.5 >We have a [rather important, it's for donors' tax receipts] report that >includes: >SELECT >items.barcode AS Barcode,items.dateaccessioned AS 'Acc Date', >biblio.title AS Title, biblio.author AS Author,biblioitems.publishercode AS >Publisher,biblioitems.publicationyear AS Year, >biblioitems.editionstatement AS Edition, >items.price as FMV, etc etc etc >It worked perfectly from 3.6.1 up to and including 3.8.4 >Since we upgraded to 3.8.5 (24 Sep, to fix bug 8520), something has changed >-- biblio.author systematically comes up empty (all 245$a fields are >present) while *all* the other field are perfect. (added later: just >checked some other reports that use biblio.author -- same result, other >fields are good, author fails.) >I've looked around release notes and bugs without finding anything >relevant, and am now at a loss as to what I should look for. >Any suggestions warmly accepted. >Thanks and regards, >Paul >_______________________________________________ >Koha-devel mailing list ><mailto:Koha-devel@lists.koha-community.org>Koha-devel(a)lists.koha-community.org > >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : <http://www.koha-community.org/>http://www.koha-community.org/ >git : <http://git.koha-community.org/>http://git.koha-community.org/ >bugs : <http://bugs.koha-community.org/>http://bugs.koha-community.org/ > > >--- >Maritime heritage and history, preservation and conservation, >research and education through the written word and the arts. ><<http://NavalMarineArchive.com>http://NavalMarineArchive.com> and ><<http://UltraMarine.ca>http://UltraMarine.ca> > >_______________________________________________ >Koha-devel mailing list ><mailto:Koha-devel@lists.koha-community.org>Koha-devel(a)lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : <http://www.koha-community.org/>http://www.koha-community.org/ >git : <http://git.koha-community.org/>http://git.koha-community.org/ >bugs : <http://bugs.koha-community.org/>http://bugs.koha-community.org/ > > >_______________________________________________ >Koha-devel mailing list ><mailto:Koha-devel@lists.koha-community.org>Koha-devel(a)lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : <http://www.koha-community.org/>http://www.koha-community.org/ >git : <http://git.koha-community.org/>http://git.koha-community.org/ >bugs : <http://bugs.koha-community.org/>http://bugs.koha-community.org/ > > >_______________________________________________ >Koha-devel mailing list >Koha-devel(a)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/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

3 3

Re: [Koha-devel] Losing biblio.author in 3.8.5
by Paul 31 Oct '12

31 Oct '12

At 08:09 PM 10/29/2012 +0100, you wrote: >>Hi Paul, >[snip] >>For your reports you always have the option to query the MARCXML data >>directly, nothing should be lost. > >I agree -- in fact for staff, I've already written a new report replacing >biblio.author with >ExtractValue(marcxml,'//datafield[@tag="100"]/subfield[@code>="a"]') and >it works perfectly. > >But this doesn't "correct" the MySQL db. Where/why on earth has it gone >wrong, and how to correct it? Could some kind soul with knowledge of using XML in MySQL assist? I'm trying to copy the XML 100$a to biblio.author where this latter is NULL, but: mysql> INSERT INTO biblio (biblio.author) -> SELECT ExtractValue(marcxml,'//datafield[@tag="100"]/subfield[@code>="a"]') FROM biblioitems -> WHERE biblio.author IS NULL; ERROR 1054 (42S22): Unknown column 'biblio.author' in 'where clause' so I tried to be more explicit for biblio.author and now the XML has an error mysql> INSERT INTO biblio (biblio.author) -> SELECT author FROM biblio, ExtractValue(marcxml,'//datafield[@tag="100"]/subfield[@code>="a"]') FROM biblioitems -> WHERE biblio.author IS NULL; ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '(marcxml,'//datafield[@tag="100"]/subfield[@code>="a"]') FROM biblioitems WHERE' at line 2 I have tried various combinations of LEFT|RIGHT JOIN biblio ON ( biblioitems.biblionumber = biblio.biblionumber) but with no success so far. Thanks and regards -- Paul >Hope that helps, > >Katrin > > >-----Ursprüngliche Nachricht----- >Von: koha-devel-bounces(a)lists.koha-community.org im Auftrag von Paul >Gesendet: Mo 29.10.2012 19:55 >An: koha-devel(a)lists.koha-community.org >Betreff: [Koha-devel] Losing biblio.author in 3.8.5 > >We have a [rather important, it's for donors' tax receipts] report that >includes: > >SELECT >items.barcode AS Barcode,items.dateaccessioned AS 'Acc Date', >biblio.title AS Title, biblio.author AS Author,biblioitems.publishercode AS >Publisher,biblioitems.publicationyear AS Year, >biblioitems.editionstatement AS Edition, >items.price as FMV, etc etc etc > >It worked perfectly from 3.6.1 up to and including 3.8.4 > >Since we upgraded to 3.8.5 (24 Sep, to fix bug 8520), something has changed >-- biblio.author systematically comes up empty (all 245$a fields are >present) while *all* the other field are perfect. (added later: just >checked some other reports that use biblio.author -- same result, other >fields are good, author fails.) > >I've looked around release notes and bugs without finding anything >relevant, and am now at a loss as to what I should look for. > >Any suggestions warmly accepted. > >Thanks and regards, >Paul > >_______________________________________________ >Koha-devel mailing list >Koha-devel(a)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/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca> _______________________________________________ Koha-devel mailing list Koha-devel(a)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/

2 1

Zebra stuff cleanup
by Tomas Cohen Arazi 31 Oct '12

31 Oct '12

Hi, I've been following the zebra-related stuff for a while and would like to ask if it'd be possible to make users use MARCXML for indexing and remove the iso options. What are your thoughts about this? If we agreed on this docs could be simplied. Otherwise we should revise the Background indexing instructions. For instance, if background indexing instructions were followed, we should explicitly state what switches should be passed to rebuild_zebra{_sliced.sh|.pl}. Regards To+

2 4

Koha 3.10, sign-off request & question
by Paul Poulain 31 Oct '12

31 Oct '12

Hello everybody, A few developer-specific news (I plan to write my monthly RM newsletter tomorrow, with more general-interest news) * I spent a lot of time in the last days QAing & pushing all bugfixes that should be included in Koha 3.10. In the "passed QA" queue and in the "signed-off" queue, there's nothing that need to be pushed before 3.10 (except a few signed-off during last european night; I'll take care of them soon) * There are some patches that require everyone attention to release a stable 3.10. Here is the list of patches that need signoff: 8919 ExtendedPatronAttributes not populated from LDAP 8832 can't enter a tax rate on vendor or when ordering 8636 Some dependencies are not listed by the installer 8378 <fine> syntax not working on overdues anymore 8945 Koha 3.10 Help Files Update 8800 SpecifyDueDate && useDaysMode=Datedue wrong behaviour 8746 rebuild_zebra_sliced.sh don't work where Record length of 106041 is larger than the MARC spec allows 4381 systempreference hide_marc = ON results in erroneous behaviour of repeatable fields and subfields 8971 Sort holds queue report using DataTables 8955 Self checkout should degrade gracefully with JavaScript turned off 8942 Translation process breaks javascript in calendar.inc 8918 ILS-DI: HoldTitle and HoldItem do not calculate rank of hold 8915 Referential integrity constraints and InnoDB vs MyISAM storage engine 8896 Delete serials no more missing from missinglist 8840 ubuntu-pkg-check.sh fix and extend functionality 8804 Quiet errors in the log from Auth.pm 8750 Chronological terms authorities not correctly indexed 8369 default_branch_circ_rule and default_circ_rules tables useless 7358 basket.pl : it is possible to affect a closed basket to a closed basketgroup 6428 refered column 'items.coded_location_qualifier' does not exist 5801 C4::Circulation::_GetCircControlBranch doesn't work in opac-reserve.pl 4481 Search's Limit to Available filters out many available items 2832 Make alphabet localizable I'd like to see all of them for 3.10, so, please signoff !!! * In the patch queue, there are also many enhancements have been signed-off and/or QAed, that could be pushed, I don't think it's good to let them pending for a long time. That's why I suggest we immediately branch 3.10.x on git. Once it's done, Jared will be responsible to push to master (starting his work for 3.12), I'll keep 3.10.x until 3.10.0 is released (exactly like RMaint does for 3.8.x : by cherry picking patches from master). I'll take care of communicating with RM to promote bugfixes that should be pushed urgently for 3.10.0. I spoke of this idea a while ago with Jared, and he agrees with this idea. -- Paul POULAIN - Associé-gérant Tel : (33) 4 91 81 35 08 http://www.biblibre.com Logiciels Libres pour les bibliothèques et les centres de documentation

2 1

Same port number mentioned in /etc/koha/koha-sites.conf
by Vimal Kumar V. 31 Oct '12

31 Oct '12

Dear Friends, See the link, http://wiki.koha-community.org/wiki/Koha_on_ubuntu_-_packages#Pre-Web_Insta… Port number 80 given in INTRAPORT and OPACPORT. It work with same port number? If its a mistake, pls correct it. Regards -- Vimal Kumar V. Mahatma Gandhi University Library Kottayam, Kerala- 686 560 Web: http://www.vimalkumar.org Blog: http://linuxhalwa.blogspot.com http://kohageek.blogspot.in --------------------------------------------------------------------------- "I forget what I was taught. I only remember what I have learnt" -Patrick White

2 1

Re: [Koha-devel] Losing biblio.author in 3.8.5
by Paul 30 Oct '12

30 Oct '12

At 08:09 PM 10/29/2012 +0100, you wrote: >Hi Paul, >the fields in biblio, biblioitems and items are connected to MARC fields >by the Koha-to-MARC-Mappings in the administration area. Have you checked >if someone changed the mapping for your author fields? Also the mappings >are 1:1, so say someone tried mapping 700, 100 would no longer be used. Hi Katrin, Thanks for the reply. "Author" is mapped to 100$a, no change from previously. But, respectfully, the point of my email was a bit different: it appears maybe that we have a "?corrupt?" MySQL db since 3.8.5 which might explain all my woes with authorities, and I don't want to have to do hundreds of INSERT ... INTO ... WHERE ... manually. The SQL structure itself appears to have changed. Here's a well snipped output of 'mysql> SELECT biblionumber, datecreated, biblio.author FROM biblio ORDER BY datecreated ASC;' : | 256 | 2011-03-10 | Arundel, Louis | 512 | 2011-03-10 | Barris, Ted | 768 | 2011-03-10 | Berton, Pierre / ... / | 18030 | 2012-09-22 | Heyerdahl, Thor | 18031 | 2012-09-23 | Cook, Graeme | 18032 | 2012-09-23 | Lubbock, Alfred Basil # # 3.8.5 upgrade this date # | 18033 | 2012-09-24 | NULL | 18034 | 2012-09-24 | NULL | 18035 | 2012-09-24 | NULL / ... / | 18363 | 2012-10-29 | NULL | 18364 | 2012-10-29 | NULL | 18365 | 2012-10-29 | NULL So it's pretty clear that 100$a is NOT being "put into the right place" in MySQL since the 3.8.5 upgrade. It's being stored somewhere, perhaps in an XML format, because if I run a Koha /tools/export.pl (and I haven't looked to see if this queries XML or not) for e.g. the last biblionumber above I get a proper 100$a: =LDR 01432nam a2200313 a 4500 =001 1906853 =003 DLC =005 20121029154904.0 =008 850207s1984\\\\onca\\\\\b\\\\000\0\eng\\ =010 \\$a 84199029 =020 \\$a0660115530 :$c{dollar}5.25 ({dollar}6.30 other countries) =040 \\$aDLC$cOPIACS$dDLC$beng =041 1\$aengfre =043 \\$an-cn-qu$an-cn-on =050 00$aHE401.O88$bL3413 1984 =082 00$a386/.48/097138$219 =100 1\$aLafreniere, Normand.$93870 =240 10$aReseau de canalisation de la riviere des Outaouais.$lEnglish =245 14$aThe Ottawa River canal system /$cNormand Lafreniere. =260 \\$a[Ottawa] :$bNational Historic Parks and Sites Branch, Parks Canada, Environment Canada ;$aHull, Quebec, Canada :$bCanadian Govt. Pub. Centre, Supply and Services Canada [distributor],$c1984. =300 \\$a95 p. :$bill. ;$c23 cm.$3pb =440 \0$aStudies in archaeology, architecture, and history,$x0821-1027$917623 =500 \\$aTranslation of: Le reseau de canalisation de la riviere des Outaouais. =504 \\$aBibliography: p. 87-95. =520 \\$aOttawa Valley, canal system =650 \0$aCanals$zOttawa River (Quand Ont.)$xHistory.$917624 =942 \\$2z$cBK =999 \\$c18365$d18365 =952 \\$w2012-10-29$p1GRLK12100005$r2012-10-29$4-2$ehhalliday$00$6GRLKLAFR2$918905$10$oGRLK-LAFR-2$d2012-10-16$zOttawa Valley, canals$8great_lak$50$71$cgreat_lak $2z$g12.00$yBK$iOttawa Valley, canals$xg pb >For your reports you always have the option to query the MARCXML data >directly, nothing should be lost. I agree -- in fact for staff, I've already written a new report replacing biblio.author with ExtractValue(marcxml,'//datafield[@tag="100"]/subfield[@code>="a"]') and it works perfectly. But this doesn't "correct" the MySQL db. Where/why on earth has it gone wrong, and how to correct it? Does this affact 'authorities'? Thanks and regards -- Paul >Hope that helps, > >Katrin > > >-----Ursprüngliche Nachricht----- >Von: koha-devel-bounces(a)lists.koha-community.org im Auftrag von Paul >Gesendet: Mo 29.10.2012 19:55 >An: koha-devel(a)lists.koha-community.org >Betreff: [Koha-devel] Losing biblio.author in 3.8.5 > >We have a [rather important, it's for donors' tax receipts] report that >includes: > >SELECT >items.barcode AS Barcode,items.dateaccessioned AS 'Acc Date', >biblio.title AS Title, biblio.author AS Author,biblioitems.publishercode AS >Publisher,biblioitems.publicationyear AS Year, >biblioitems.editionstatement AS Edition, >items.price as FMV, etc etc etc > >It worked perfectly from 3.6.1 up to and including 3.8.4 > >Since we upgraded to 3.8.5 (24 Sep, to fix bug 8520), something has changed >-- biblio.author systematically comes up empty (all 245$a fields are >present) while *all* the other field are perfect. (added later: just >checked some other reports that use biblio.author -- same result, other >fields are good, author fails.) > >I've looked around release notes and bugs without finding anything >relevant, and am now at a loss as to what I should look for. > >Any suggestions warmly accepted. > >Thanks and regards, >Paul > >_______________________________________________ >Koha-devel mailing list >Koha-devel(a)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/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

1 0

Migration of list servers to a new server
by Paul Poulain 30 Oct '12

30 Oct '12

Hello koha lists, It's time for our mail server to retire and be replaced by a new (virtual) one. The migration will be made during the night (european time) of nov 5th. We have a backup MX so no mail should be lost in the process. We also will move the history to the new server. The only possible loss could be in the history, in case a message is sent and distributed to the old server once the migration has started. I suggest you avoid sending mails during mon 2 tue (european) night. -- Paul POULAIN - Associé-gérant Tel : (33) 4 91 81 35 08 http://www.biblibre.com Logiciels Libres pour les bibliothèques et les centres de documentation

2 1