From danielg.koha at gmail.com Tue Jan 1 19:15:23 2013 From: danielg.koha at gmail.com (Daniel Grobani) Date: Tue, 1 Jan 2013 10:15:23 -0800 Subject: [Koha-devel] December Koha Community Newsletter has been published Message-ID: Hi, The December 2012 edition of the Koha Community Newsletter has been posted to http://koha-community.org/koha-community-newsletter-december-2012/ . Cheers, Daniel Grobani Koha Community Newsletter Editor -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielg.koha at gmail.com Wed Jan 2 01:36:12 2013 From: danielg.koha at gmail.com (Daniel Grobani) Date: Tue, 1 Jan 2013 16:36:12 -0800 Subject: [Koha-devel] December Koha Community Newsletter has been published In-Reply-To: References: Message-ID: Hi again, Sorry, there's a problem with that link--it should be http://koha-community.org/koha-community-newsletter-december-2012/. Cheers, Daniel On Tue, Jan 1, 2013 at 10:15 AM, Daniel Grobani wrote: > > Hi, > > The December 2012 edition of the Koha Community Newsletter has been posted to http://koha-community.org/koha-community-newsletter-december-2012/ . > > Cheers, > > Daniel Grobani > Koha Community Newsletter Editor -------------- next part -------------- An HTML attachment was scrubbed... URL: From samuel.desseaux at ecp.fr Wed Jan 2 11:30:40 2013 From: samuel.desseaux at ecp.fr (Samuel desseaux) Date: Wed, 02 Jan 2013 11:30:40 +0100 Subject: [Koha-devel] koha as a cms Message-ID: <50E40C50.2010900@ecp.fr> Hi, I try to use koha as cms, in waiting for our new website. I've followed these links http://manual.koha-community.org/3.8/en/kohacms.html and http://wiki.koha-community.org/wiki/Koha_as_a_CMS I've no error but the content can't be displayed. What i don't understand is "pages.tmpl". In /usr/share/koha/opac/htdocs/opac-tmpl/prog/fr-FR/modules , i've only pages.tt. Do i have to change tt in tmpl? Permissions, user and group are ok. Best regards samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: samuel_desseaux.vcf Type: text/x-vcard Size: 350 bytes Desc: not available URL: From paul.poulain at biblibre.com Wed Jan 2 11:30:46 2013 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 02 Jan 2013 11:30:46 +0100 Subject: [Koha-devel] Database updates In-Reply-To: References: Message-ID: <50E40C56.3060708@biblibre.com> Le 27/12/2012 18:01, Jared Camins-Esakov a ?crit : > Hello. > > I just pushed bug 7167, which changes the way database updates work. I > wrote up instructions for database updates > at http://wiki.koha-community.org/wiki/Database_updates#Using_the_new_update_procedure > > Please be sure to read those instructions and follow them in the future. Hi Jared, (and happy new year everyone !) How should be handle pending patches with a DB update ? (question asked for each role : submitter, signer, QAer) Should someone update the patch to use the new DB update schema ? if no, how should/can we test patches with the old schema ? ( Thanks for pushing this patch though ! ) -- Paul POULAIN - BibLibre http://www.biblibre.com Free & Open Source Softwares for libraries Koha, Drupal, Piwik, Jasper From chris at bigballofwax.co.nz Wed Jan 2 11:42:22 2013 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Wed, 2 Jan 2013 23:42:22 +1300 Subject: [Koha-devel] Database updates In-Reply-To: <50E40C56.3060708@biblibre.com> References: <50E40C56.3060708@biblibre.com> Message-ID: The patches were reverted (it broke installing) so no change yet I don't think . Also I will not be pushing it to 3.10.x so if anything is for 3.10.x and needs a db change, when this patch is pushed, we will need 2 sets of db changes. Chris On Jan 2, 2013 11:31 PM, "Paul Poulain" wrote: > Le 27/12/2012 18:01, Jared Camins-Esakov a ?crit : > > Hello. > > > > I just pushed bug 7167, which changes the way database updates work. I > > wrote up instructions for database updates > > at > http://wiki.koha-community.org/wiki/Database_updates#Using_the_new_update_procedure > > > > Please be sure to read those instructions and follow them in the future. > Hi Jared, (and happy new year everyone !) > > How should be handle pending patches with a DB update ? (question asked > for each role : submitter, signer, QAer) > > Should someone update the patch to use the new DB update schema ? if no, > how should/can we test patches with the old schema ? > > ( Thanks for pushing this patch though ! ) > > -- > Paul POULAIN - BibLibre > http://www.biblibre.com > Free & Open Source Softwares for libraries > Koha, Drupal, Piwik, Jasper > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zahidiqbal_isb at yahoo.com Wed Jan 2 14:24:48 2013 From: zahidiqbal_isb at yahoo.com (Zahid Iqbal) Date: Wed, 2 Jan 2013 05:24:48 -0800 (PST) Subject: [Koha-devel] searching problem in marc tags in koha 3.4 Message-ID: <1357133088.73394.YahooMailClassic@web110302.mail.gq1.yahoo.com> I am running koha 3.4 on ubuntu zebra index is enabled. i have a problem when some information is written/added to marc tag 773 (g) and 546 (a) and this information is not search by koha for example: 773 ## - HOST ITEM ENTRY g Relationship information 546 ## - LANGUAGE NOTE a Language note information written in both these tags 773(g) and 546(a) are not been searched in koha using catalog searching even in advance search it cannot search. do i have to modify the code or zebra index file or both? i have no idea why it is not searching? can some body please help me ? Regards, Zahid Iqbal -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcamins at cpbibliography.com Wed Jan 2 15:15:20 2013 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Wed, 2 Jan 2013 09:15:20 -0500 Subject: [Koha-devel] Database updates In-Reply-To: <50E40C56.3060708@biblibre.com> References: <50E40C56.3060708@biblibre.com> Message-ID: Paul, > I just pushed bug 7167, which changes the way database updates work. I > > wrote up instructions for database updates > > at > http://wiki.koha-community.org/wiki/Database_updates#Using_the_new_update_procedure > > > > Please be sure to read those instructions and follow them in the future. > Hi Jared, (and happy new year everyone !) > > How should be handle pending patches with a DB update ? (question asked > for each role : submitter, signer, QAer) > > Should someone update the patch to use the new DB update schema ? if no, > how should/can we test patches with the old schema ? > > ( Thanks for pushing this patch though ! ) > Once the needed follow-ups are signed off and the feature is re-pushed, it will be the responsibility of the QAer to copy the database update from updatedatabase.pl to a new-style update for SQL-only updates (for complex updates that are not simply copy-paste, we will probably have to send the patch back to the author for revision). For bugs that are not signed off, the author will need to move the database update, unless someone else volunteers to do it for them. Also, I have a correction to Chris's response: we will not need two separate sets of DB changes because I will be copying every non-linear update into updatedatabase.pl. That was the reason for the CheckVersion() routine. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins at cpbibliography.com (web) http://www.cpbibliography.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Wed Jan 2 16:42:36 2013 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 02 Jan 2013 16:42:36 +0100 Subject: [Koha-devel] Database updates In-Reply-To: References: <50E40C56.3060708@biblibre.com> Message-ID: <50E4556C.6080904@biblibre.com> Le 02/01/2013 15:15, Jared Camins-Esakov a ?crit : > > Also, I have a correction to Chris's response: we will not need two > separate sets of DB changes because I will be copying every non-linear > update into updatedatabase.pl . That was the > reason for the CheckVersion() routine. > Just to be sure I understand well. You will *copy* things into updatedatabase.pl when pushing to stable. Thus, we will have the patch in both old and new mechanism ? The koha 3.12 will use the new mechanism and 3.10.x will use the old one ? How will Koha behave for people upgrading from 3.10.x to 3.12 (once it's released, of course), where a db change will have been applied with the old mechanism and will be re-applied with the new one ? (I think the new mechanism will just issue an error message about, for example a "duplicate entry in XXX" or "already existing column YYYY" or "cannot find xxx" (because it has already been removed and cannot be removed again). If I'm right, then we just will have to warn in the new mechanism comment "if you see message xxx, it means this change had already been applied, and you can force apply it safely" For those who don't know how the new mechanism will work (internally) : each DB change, if there's an error thrown will appear as "failing", with the error message. The administrator can then "force apply" a DB revision. In this case, Koha will just mark "OK, this DB change is done" (happy new year again!) -- 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 From chris at bigballofwax.co.nz Wed Jan 2 19:10:27 2013 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Thu, 3 Jan 2013 07:10:27 +1300 Subject: [Koha-devel] Database updates In-Reply-To: References: <50E40C56.3060708@biblibre.com> Message-ID: On Jan 3, 2013 3:15 AM, "Jared Camins-Esakov" wrote: > > Paul, > >> > I just pushed bug 7167, which changes the way database updates work. I >> > wrote up instructions for database updates >> > at http://wiki.koha-community.org/wiki/Database_updates#Using_the_new_update_procedure >> > >> > Please be sure to read those instructions and follow them in the future. >> Hi Jared, (and happy new year everyone !) >> >> How should be handle pending patches with a DB update ? (question asked >> for each role : submitter, signer, QAer) >> >> Should someone update the patch to use the new DB update schema ? if no, >> how should/can we test patches with the old schema ? >> >> ( Thanks for pushing this patch though ! ) > > > Once the needed follow-ups are signed off and the feature is re-pushed, it will be the responsibility of the QAer to copy the database update from updatedatabase.pl to a new-style update for SQL-only updates (for complex updates that are not simply copy-paste, we will probably have to send the patch back to the author for revision). For bugs that are not signed off, the author will need to move the database update, unless someone else volunteers to do it for them. > > Also, I have a correction to Chris's response: we will not need two separate sets of DB changes because I will be copying every non-linear update into updatedatabase.pl. That was the reason for the CheckVersion() routine. > Hi While that is a good idea, and will mean the packages aren't totally busted on master. A commit that has both the old safe updatedatabase and the new system is no use for cherry-picking to stable. It won't apply. So we will need a commit with just the bug fix, then another 2 commits, one doing old db update, one doing new, and I will just cherry pick the old one. IE if something is needed for 3.10.x or 3.8.x it can't combine the db update part of the patch with the rest, for it to be able to apply. Chris > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcamins at cpbibliography.com Wed Jan 2 19:16:33 2013 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Wed, 2 Jan 2013 13:16:33 -0500 Subject: [Koha-devel] Database updates In-Reply-To: References: <50E40C56.3060708@biblibre.com> Message-ID: Chris, > Also, I have a correction to Chris's response: we will not need two > separate sets of DB changes because I will be copying every non-linear > update into updatedatabase.pl. That was the reason for the CheckVersion() > routine. > > > > Hi > > While that is a good idea, and will mean the packages aren't totally > busted on master. A commit that has both the old safe updatedatabase and > the new system is no use for cherry-picking to stable. It won't apply. So > we will need a commit with just the bug fix, then another 2 commits, one > doing old db update, one doing new, and I will just cherry pick the old > one. > > IE if something is needed for 3.10.x or 3.8.x it can't combine the db > update part of the patch with the rest, for it to be able to apply. > Sure it can. The DB update for 3.12+ will be a new file (which will be ignored by every version up until 3.12), every time. Any patches that make changes to the update system itself will have to be on different bugs, of course, but I was going to require that anyway. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins at cpbibliography.com (web) http://www.cpbibliography.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisc at catalyst.net.nz Wed Jan 2 19:19:11 2013 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Thu, 03 Jan 2013 07:19:11 +1300 Subject: [Koha-devel] Database updates In-Reply-To: References: <50E40C56.3060708@biblibre.com> Message-ID: Nope, that file won't exist in stable, and every patch that references it will fail to apply. I repeat I am not pushing anything to do with 7167 to stable . Including a file that we ignore. Chris Jared Camins-Esakov wrote: >Chris, > >> Also, I have a correction to Chris's response: we will not need two >> separate sets of DB changes because I will be copying every >non-linear >> update into updatedatabase.pl. That was the reason for the >CheckVersion() >> routine. >> > >> >> Hi >> >> While that is a good idea, and will mean the packages aren't totally >> busted on master. A commit that has both the old safe updatedatabase >and >> the new system is no use for cherry-picking to stable. It won't >apply. So >> we will need a commit with just the bug fix, then another 2 commits, >one >> doing old db update, one doing new, and I will just cherry pick the >old >> one. >> >> IE if something is needed for 3.10.x or 3.8.x it can't combine the db >> update part of the patch with the rest, for it to be able to apply. >> > >Sure it can. The DB update for 3.12+ will be a new file (which will be >ignored by every version up until 3.12), every time. Any patches that >make >changes to the update system itself will have to be on different bugs, >of >course, but I was going to require that anyway. > >Regards, >Jared > >-- >Jared Camins-Esakov >Bibliographer, C & P Bibliography Services, LLC >(phone) +1 (917) 727-3445 >(e-mail) jcamins at cpbibliography.com >(web) http://www.cpbibliography.com/ > > >------------------------------------------------------------------------ > >_______________________________________________ >Koha-devel mailing list >Koha-devel at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nguyenquocuy_1102 at yahoo.com Fri Jan 4 00:01:25 2013 From: nguyenquocuy_1102 at yahoo.com (Quoc Uy) Date: Thu, 3 Jan 2013 15:01:25 -0800 (PST) Subject: [Koha-devel] Can we create templates for branches. Message-ID: <1357254085.4859.YahooMailNeo@web124506.mail.ne1.yahoo.com> ? ? ? ? ? ?My idea comes from creating 1 Koha installed with 1 Database for 100 small branches libraries. Each branch has separated template OPAC. ?There should be a folder in koha and logic in the application that saying ... ok, load branchA's template OPAC for BranchA's user when they login.?A,B or C are diff branch libraries,?they can have there own data set?and can share if possible (it has done quite well with independent branches preference now). Hope some one can improve this! Sorry for my bad English! Best regards! -------------- next part -------------- An HTML attachment was scrubbed... URL: From bibliwho at gmail.com Fri Jan 4 00:10:47 2013 From: bibliwho at gmail.com (Cab Vinton) Date: Thu, 3 Jan 2013 18:10:47 -0500 Subject: [Koha-devel] 952 $6 subfield question Message-ID: Hi, All -- We're using Terry Reese's new MarcEdit plugin to update records in Koha and I'm unclear on how we should be handling the 952 $6 subfield (normalized classification for sorting). Further info about the plugin here: http://people.oregonstate.edu/~reeset/blog/archives/1135 Specifically, if we update the 952 $o (call number) using the plugin, will the $6 be automatically updated? For example, when correcting records we could do any of the following: 1. $6A_FIC_RU$oA FIC RUN -- leave incorrect $6 and update $o only 2. $6A_FIC_RUN$oA FIC RUN -- fix both incorrect $6 and incorrect $o 3. $oA FIC RUN -- delete incorrect $6 and update $o Any thoughts on which of these approaches is preferable? 1 and 3 assume that Koha will update $6 based on the new data in $o. Thank you, Cab Vinton, Director Sanbornton Public Library Sanbornton, NH Life is short. Read fast! From liz at catalyst.net.nz Fri Jan 4 00:17:51 2013 From: liz at catalyst.net.nz (Liz Rea) Date: Fri, 04 Jan 2013 12:17:51 +1300 Subject: [Koha-devel] Can we create templates for branches. In-Reply-To: <1357254085.4859.YahooMailNeo@web124506.mail.ne1.yahoo.com> References: <1357254085.4859.YahooMailNeo@web124506.mail.ne1.yahoo.com> Message-ID: <50E6119F.4030106@catalyst.net.nz> I think what you want is not entirely impossible, but I can say that it would likely be a lot of work to maintain. A few years ago we had a RFC for the following work, which was never done but I think would do something similar to what you are describing, and possibly be easier to maintain through upgrades: http://wiki.koha-community.org/wiki/Support_for_multiple_PAC_interfaces_by_URL_RFC Liz Rea On 04/01/13 12:01, Quoc Uy wrote: > My idea comes from creating 1 Koha installed with 1 > Database for 100 small branches libraries. Each branch has separated > template OPAC. There should be a folder in koha and logic in the > application that saying ... ok, load branchA's template OPAC for > BranchA's user when they login. A,B or C are diff branch > libraries, they can have there own data set and can share if possible > (it has done quite well with independent branches preference now). > Hope some one can improve this! Sorry for my bad English! > > Best regards! > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmc at esilibrary.com Fri Jan 4 00:23:41 2013 From: gmc at esilibrary.com (Galen Charlton) Date: Thu, 3 Jan 2013 15:23:41 -0800 Subject: [Koha-devel] 952 $6 subfield question In-Reply-To: References: Message-ID: Hi, On Thu, Jan 3, 2013 at 3:10 PM, Cab Vinton wrote: > 1. $6A_FIC_RU$oA FIC RUN -- leave incorrect $6 and update $o only > > 2. $6A_FIC_RUN$oA FIC RUN -- fix both incorrect $6 and incorrect $o > > 3. $oA FIC RUN -- delete incorrect $6 and update $o > > Any thoughts on which of these approaches is preferable? 1 and 3 > assume that Koha will update $6 based on the new data in $o. > As long as the call number is supplied, Koha will recalculate items.cn_sort, so either 1 or 3 will work. Regards, Galen -- Galen Charlton Director of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From liz at catalyst.net.nz Fri Jan 4 00:49:01 2013 From: liz at catalyst.net.nz (Liz Rea) Date: Fri, 04 Jan 2013 12:49:01 +1300 Subject: [Koha-devel] Can we create templates for branches. In-Reply-To: <50E6119F.4030106@catalyst.net.nz> References: <1357254085.4859.YahooMailNeo@web124506.mail.ne1.yahoo.com> <50E6119F.4030106@catalyst.net.nz> Message-ID: <50E618ED.5030705@catalyst.net.nz> Actually, upon further review I find that this work *was* done, and you can simply create multiple virtualhosts, each with a unique URL, and specify a CSS file to use for each one. Details can be found in the koha-httpd.conf file. Liz Rea On 04/01/13 12:17, Liz Rea wrote: > I think what you want is not entirely impossible, but I can say that > it would likely be a lot of work to maintain. > > A few years ago we had a RFC for the following work, which was never > done but I think would do something similar to what you are > describing, and possibly be easier to maintain through upgrades: > > http://wiki.koha-community.org/wiki/Support_for_multiple_PAC_interfaces_by_URL_RFC > > Liz Rea > On 04/01/13 12:01, Quoc Uy wrote: >> My idea comes from creating 1 Koha installed with 1 >> Database for 100 small branches libraries. Each branch has separated >> template OPAC. There should be a folder in koha and logic in the >> application that saying ... ok, load branchA's template OPAC for >> BranchA's user when they login. A,B or C are diff branch >> libraries, they can have there own data set and can share if possible >> (it has done quite well with independent branches preference now). >> Hope some one can improve this! Sorry for my bad English! >> >> Best regards! >> >> >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at 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/ > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashokmishra119 at gmail.com Fri Jan 4 07:52:36 2013 From: ashokmishra119 at gmail.com (Ashok Mishra) Date: Fri, 4 Jan 2013 12:22:36 +0530 Subject: [Koha-devel] formal Message-ID: yes sir thanks -- Ashok Mishra *Librarian* Bansal College of Pharmacy, Bhopal -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.saby at univ-rennes2.fr Fri Jan 4 10:17:31 2013 From: mathieu.saby at univ-rennes2.fr (Mathieu Saby) Date: Fri, 04 Jan 2013 10:17:31 +0100 Subject: [Koha-devel] using new templates for exporting basketgroups in pdf In-Reply-To: <50C76E50.8000407@univ-rennes2.fr> References: <50C76E50.8000407@univ-rennes2.fr> Message-ID: <50E69E2B.3020707@univ-rennes2.fr> 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 "

Invalid PDF Format set

"; > 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 > -- 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 at univ-rennes2.fr From jonathan.field at ptfs-europe.com Fri Jan 4 13:17:56 2013 From: jonathan.field at ptfs-europe.com (Jonathan Field) Date: Fri, 4 Jan 2013 12:17:56 +0000 Subject: [Koha-devel] Can we create templates for branches. In-Reply-To: <50E618ED.5030705@catalyst.net.nz> References: <1357254085.4859.YahooMailNeo@web124506.mail.ne1.yahoo.com> <50E6119F.4030106@catalyst.net.nz> <50E618ED.5030705@catalyst.net.nz> Message-ID: I've had a play with this in the past and it works nicely. You just add the config options to your VirtualHost in Apache SetEnvIf Host "demo1.xxx.xxx.xxx" OPAC_CSS_OVERRIDE=opac-main.css OPAC_SEARCH_ LIMIT=branch:MAIN OPAC_LIMIT_OVERRIDE=1 SetEnvIf Host "demo2.xxx.xxx.xxx" OPAC_CSS_OVERRIDE=opac-branch.css OPAC_SEARCH_ LIMIT=branch:BRANCH OPAC_LIMIT_OVERRIDE=1 You have to address the OPAC by the correct hostname of course. So, in this case, demo1.xxx.xxx.xxx would default to searching the MAIN library and demo2 the BRANCH. Jonathan On 3 January 2013 23:49, Liz Rea wrote: > Actually, upon further review I find that this work *was* done, and you can > simply create multiple virtualhosts, each with a unique URL, and specify a > CSS file to use for each one. Details can be found in the koha-httpd.conf > file. > > Liz Rea > > On 04/01/13 12:17, Liz Rea wrote: > > I think what you want is not entirely impossible, but I can say that it > would likely be a lot of work to maintain. > > A few years ago we had a RFC for the following work, which was never done > but I think would do something similar to what you are describing, and > possibly be easier to maintain through upgrades: > > http://wiki.koha-community.org/wiki/Support_for_multiple_PAC_interfaces_by_URL_RFC > > Liz Rea > On 04/01/13 12:01, Quoc Uy wrote: > > My idea comes from creating 1 Koha installed with 1 Database for > 100 small branches libraries. Each branch has separated template OPAC. > There should be a folder in koha and logic in the application that saying > ... ok, load branchA's template OPAC for BranchA's user when they login. A,B > or C are diff branch libraries, they can have there own data set and can > share if possible (it has done quite well with independent branches > preference now). Hope some one can improve this! Sorry for my bad English! > > Best regards! > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ -- Jonathan Field Technical Director, PTFS Europe Limited jonathan.field at ptfs-europe.com http://www.ptfs-europe.com From veron at veron.ch Fri Jan 4 14:07:07 2013 From: veron at veron.ch (=?ISO-8859-1?Q?Marc_V=E9ron?=) Date: Fri, 04 Jan 2013 14:07:07 +0100 Subject: [Koha-devel] using new templates for exporting basketgroups in pdf In-Reply-To: <50E69E2B.3020707@univ-rennes2.fr> References: <50C76E50.8000407@univ-rennes2.fr> <50E69E2B.3020707@univ-rennes2.fr> Message-ID: <50E6D3FB.8020303@veron.ch> 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 "

Invalid PDF Format set

"; >> 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 >> > > From mathieu.saby at univ-rennes2.fr Fri Jan 4 14:42:49 2013 From: mathieu.saby at univ-rennes2.fr (Mathieu Saby) Date: Fri, 04 Jan 2013 14:42:49 +0100 Subject: [Koha-devel] using new templates for exporting basketgroups in pdf In-Reply-To: <50E6D3FB.8020303@veron.ch> References: <50C76E50.8000407@univ-rennes2.fr> <50E69E2B.3020707@univ-rennes2.fr> <50E6D3FB.8020303@veron.ch> Message-ID: <50E6DC59.2010006@univ-rennes2.fr> 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 "

Invalid PDF Format set

"; >>> 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 at 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 at univ-rennes2.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: From fridolyn.somers at biblibre.com Fri Jan 4 17:46:39 2013 From: fridolyn.somers at biblibre.com (Fridolyn SOMERS) Date: Fri, 04 Jan 2013 17:46:39 +0100 Subject: [Koha-devel] KOCT and FF 18 Message-ID: <50E7076F.8050409@biblibre.com> Hie, Good news : Firefox add-on KOCT sucessfully passed compatibility test with Firefox 18. https://addons.mozilla.org/fr/firefox/addon/koct/ Best regards, -- Fridolyn SOMERS Biblibre - P?le Support fridolyn.somers at biblibre.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From nguyenquocuy_1102 at yahoo.com Sat Jan 5 14:08:32 2013 From: nguyenquocuy_1102 at yahoo.com (Quoc Uy) Date: Sat, 5 Jan 2013 05:08:32 -0800 (PST) Subject: [Koha-devel] Can we create templates for branches. Message-ID: <1357391312.56427.YahooMailNeo@web124504.mail.ne1.yahoo.com> To Liz and Jonathan: What you two said is similar:?http://wiki.koha-community.org/wiki/Support_for_multiple_PAC_interfaces_by_URL_RFC I'm not sure about what you are talking is about independent branches or separated instances. Now we can create a lot of instances with only one Koha installation, each instance has its own database, URL (opac and intranet), and of course they have their own CSS, HTML templates. But it's not what i mean. Branches use only 1 shared database, and all user only need to access to only one URL, and only when they login, they will see different interfaces, based on branch library they registered. If we have only 1 databases for 100 branches, it's easy for us to maintenance, manage, control system preferences. It goes with SYS.Pref Independent branches turn to ON. Sorry for any miss-understanding. Best regards! -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.renvoize at ptfs-europe.com Mon Jan 7 10:40:00 2013 From: martin.renvoize at ptfs-europe.com (Martin Renvoize) Date: Mon, 7 Jan 2013 09:40:00 +0000 Subject: [Koha-devel] Can we create templates for branches. In-Reply-To: <1357391312.56427.YahooMailNeo@web124504.mail.ne1.yahoo.com> References: <1357391312.56427.YahooMailNeo@web124504.mail.ne1.yahoo.com> Message-ID: Hi Quoc Uy, I've got a feeling your misunderstanding the virtual hosts set-up that Jonathan and Liz are talking about. In the setup described you are using one koha install with on database and one staff client. The big difference is that your using multiple OPAC's for that single koha instance so you can give each library their own opac style. So you end up with a custom opac with it's own unique url for each branch. I don't believe the functionality your looking for to change the styling only upon login on one url currently exists. Martin On 5 January 2013 13:08, Quoc Uy wrote: > To Liz and Jonathan: What you two said is similar: > http://wiki.koha-community.org/wiki/Support_for_multiple_PAC_interfaces_by_URL_RFC > I'm not sure about what you are talking is about independent branches or > separated instances. Now we can create a lot of instances with only one > Koha installation, each instance has its own database, URL (opac and > intranet), and of course they have their own CSS, HTML templates. But it's > not what i mean. > Branches use only 1 shared database, and all user only need to access to > only one URL, and only when they login, they will see different interfaces, > based on branch library they registered. If we have only 1 databases for > 100 branches, it's easy for us to maintenance, manage, control system > preferences. It goes with SYS.Pref Independent branches turn to ON. > Sorry for any miss-understanding. > Best regards! > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -- Martin Renvoize Software Engineer, PTFS Europe Ltd Content Management and Library Solutions Skype: Mobile: 07725985636 http://www.ptfs-europe.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.saby at univ-rennes2.fr Mon Jan 7 16:51:34 2013 From: mathieu.saby at univ-rennes2.fr (Mathieu Saby) Date: Mon, 07 Jan 2013 16:51:34 +0100 Subject: [Koha-devel] Why not copying serial holdings in Marc records? Message-ID: <50EAEF06.3070509@univ-rennes2.fr> Today, information about serial is only stored in MySQL database. As as consequency (correct me if I am wrong...), callnumber, holding library, location, notes are not searchable in OPAC, because Zebra cannot index them. One solution could be to copy serial information in Marc structure as does, for example, Sudoc network in France (955 field is used : http://documentation.abes.fr/sudoc/formats/loc/zones/955.htm ) What do you think about it? Regards, M. Saby Rennes 2 University -- 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 at univ-rennes2.fr From jonathan.druart at biblibre.com Tue Jan 8 12:50:59 2013 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Tue, 8 Jan 2013 12:50:59 +0100 Subject: [Koha-devel] Sign-off on several patches Message-ID: Hi all, I just added a new git alias in my git config file to sign-off many patches with a single command. It is: so = "!f() { c=`expr $1 - 1`; git filter-branch -f --msg-filter \"cat && echo \\\"\nSigned-off-by: Your Name \\\"\" HEAD~$c^..; }; f" Until you have this alias defined, you can signed-off the number of patches you want with the following git command: git so X Hope this helps, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjr at phonecoop.coop Tue Jan 8 18:39:03 2013 From: mjr at phonecoop.coop (MJ Ray) Date: Tue, 08 Jan 2013 17:39:03 +0000 Subject: [Koha-devel] Why not copying serial holdings in Marc records? In-Reply-To: <50EAEF06.3070509@univ-rennes2.fr> Message-ID: Mathieu Saby > Today, information about serial is only stored in MySQL database. [...] > One solution could be to copy serial information in Marc structure as > does, for example, Sudoc network in France (955 field is used : > http://documentation.abes.fr/sudoc/formats/loc/zones/955.htm ) > > What do you think about it? Sounds good to me. I guess it will need another table in the Koha-to-MARC mappings so we can handle it differently for each MARC flavour. Anyone know what the defaults for other MARCs would be? Thanks, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/ From mathieu.saby at univ-rennes2.fr Tue Jan 8 18:51:59 2013 From: mathieu.saby at univ-rennes2.fr (Mathieu Saby) Date: Tue, 08 Jan 2013 18:51:59 +0100 Subject: [Koha-devel] Why not copying serial holdings in Marc records? In-Reply-To: References: Message-ID: <50EC5CBF.6010007@univ-rennes2.fr> I think there is a standard used in Marc21 format for holdings : ISO 10324 http://www.loc.gov/marc/holdings/hdintro.html http://www.itsmarc.com/crs/mergedProjects/holdings/holdings/appendix_d_ansi_niso_z39_71_and_iso_10324_data_elements.htm There is something similar for Unimarc http://archive.ifla.org/VI/8/projects/UNIMARC-HoldingsFormat.pdf BUT... it is not used in France http://www.bnf.fr/fr/professionnels/f_um/s.format_unimarc_donnees_local.html?first_Art=non Regards M. Saby MJ Ray a ?crit : > Mathieu Saby > >> Today, information about serial is only stored in MySQL database. [...] >> One solution could be to copy serial information in Marc structure as >> does, for example, Sudoc network in France (955 field is used : >> http://documentation.abes.fr/sudoc/formats/loc/zones/955.htm ) >> >> What do you think about it? >> > > Sounds good to me. I guess it will need another table in the > Koha-to-MARC mappings so we can handle it differently for each MARC > flavour. Anyone know what the defaults for other MARCs would be? > > Thanks, > -- 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 at univ-rennes2.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: From mh_zalabany at hotmail.com Tue Jan 8 19:34:08 2013 From: mh_zalabany at hotmail.com (Mohamed zalabany) Date: Tue, 8 Jan 2013 18:34:08 +0000 Subject: [Koha-devel] need help in error in koha 3.6.4 Message-ID: hi alli have system running on koha 3.6.4 with no zebrasuddenly message appear when we are saving bib records the message Software error:Can't call method "as_usmarc" on an undefined value at /usr/share/koha/lib/C4/Search.pm line 2524.did any one faced this error before i need to solve this problemthanks for your help Mohamed El Zalabany Integrated library systems consultant mh_zalabany at hotmail.com Mobile: 0111291444 -------------- next part -------------- An HTML attachment was scrubbed... URL: From veron at veron.ch Tue Jan 8 19:58:30 2013 From: veron at veron.ch (=?ISO-8859-1?Q?Marc_V=E9ron?=) Date: Tue, 08 Jan 2013 19:58:30 +0100 Subject: [Koha-devel] need help in error in koha 3.6.4 In-Reply-To: References: Message-ID: <50EC6C56.7090603@veron.ch> Hi, NoZebra is deprecated since 3.4.0 See e.g. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7440 http://lists.katipo.co.nz/public/koha/2011-April/028711.html Current Koha Version is 3.10 HTH Marc Am 08.01.2013 19:34, schrieb Mohamed zalabany: > hi all > i have system running on koha 3.6.4 with no zebra > suddenly message appear when we are saving bib records > > the message > > > Software error: > > Can't call method "as_usmarc" on an undefined value at /usr/share/koha/lib/C4/Search.pm line 2524. > > did any one faced this error before > > i need to solve this problem > > thanks for your help > > > > > Mohamed El Zalabany > Integrated library systems consultant > > * > *mh_zalabany at hotmail.com > Mobile: 0111291444 > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > From oleonard at myacpl.org Tue Jan 8 22:20:50 2013 From: oleonard at myacpl.org (Owen Leonard) Date: Tue, 8 Jan 2013 16:20:50 -0500 Subject: [Koha-devel] IRC meeting reminder: 9 January 2013 at 10:00 UTC Message-ID: The next general IRC meeting is coming up soon: 9 January 2013, at 10:00 UTC http://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+IRC+General+Meeting&iso=20130109T10 The agenda is here: http://wiki.koha-community.org/wiki/General_IRC_meeting,_9_January_2013 I hope to see you there, Owen From bgkriegel at gmail.com Tue Jan 8 23:29:22 2013 From: bgkriegel at gmail.com (Bernardo Gonzalez Kriegel) Date: Tue, 8 Jan 2013 19:29:22 -0300 Subject: [Koha-devel] About bug 5634 - Ordering branches should be case independent Message-ID: Hi, I've been studying the code to hopefully find (and eventually fix) all occurrences of code to display an ordered list of branches, to close Bug 5634 [1] There is a zoo of different versions, so I have some questions: 1) It's desirable to change the code to use GetBranchesLoop() whenever possible, or only fix the sort order in place? 2) Some solutions use CGI::scrolling_list() to draw the drop down list. This simplifies the template, but is more code in the script. Which version do you think is better? Regards, Bernardo [1] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5634 -- Bernardo Gonzalez Kriegel bgkriegel at gmail.com From gmc at esilibrary.com Wed Jan 9 00:00:00 2013 From: gmc at esilibrary.com (Galen Charlton) Date: Tue, 8 Jan 2013 15:00:00 -0800 Subject: [Koha-devel] About bug 5634 - Ordering branches should be case independent In-Reply-To: References: Message-ID: Hi, On Tue, Jan 8, 2013 at 2:29 PM, Bernardo Gonzalez Kriegel < bgkriegel at gmail.com> wrote: > 2) Some solutions use CGI::scrolling_list() to draw the drop down list. > This simplifies the template, but is more code in the script. > Which version do you think is better? > CGI::scrolling_list() has been deprecated for a long time (see bug 766 [1]), so it shouldn't be part of any solution for bug 5634. [1] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=766 Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisc at catalyst.net.nz Wed Jan 9 00:30:28 2013 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Wed, 09 Jan 2013 12:30:28 +1300 Subject: [Koha-devel] About bug 5634 - Ordering branches should be case independent In-Reply-To: References: Message-ID: <8ffac0b8-d486-4dbc-a339-502007d06163@email.android.com> Bernardo Gonzalez Kriegel wrote: >Hi, >I've been studying the code to hopefully find (and eventually fix) >all occurrences of code to display an ordered list of branches, >to close Bug 5634 [1] > >There is a zoo of different versions, so I have some questions: > >1) It's desirable to change the code to use GetBranchesLoop() >whenever possible, or only fix the sort order in place? > >2) Some solutions use CGI::scrolling_list() to draw the drop down list. >This simplifies the template, but is more code in the script. >Which version do you think is better? CGI::scrolling_list should be removed wherever it is found, it renders the contents untranslatable. Chris > >Regards, >Bernardo > >[1] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5634 From veron at veron.ch Wed Jan 9 07:11:14 2013 From: veron at veron.ch (=?ISO-8859-1?Q?Marc_V=E9ron?=) Date: Wed, 09 Jan 2013 07:11:14 +0100 Subject: [Koha-devel] About bug 5634 - Ordering branches should be case independent In-Reply-To: <8ffac0b8-d486-4dbc-a339-502007d06163@email.android.com> References: <8ffac0b8-d486-4dbc-a339-502007d06163@email.android.com> Message-ID: <50ED0A02.60009@veron.ch> I did a search for scrolling_list on current master and found 79 hits in 34 files: acqui\fetch_sort_dropbox.pl admin\aqplan.pl admin\authorised_values.pl admin\auth_subfields_structure.pl admin\auth_tag_structure.pl admin\koha2marclinks.pl admin\marctagstructure.pl admin\marc_subfields_structure.pl authorities\authorities.pl C4\Input.pm C4\Items.pm C4\Reports.pm catalogue\labeledMARCdetail.pl cataloguing\addbiblio.pl cataloguing\additem.pl cataloguing\value_builder\marc21_linking_section.pl cataloguing\value_builder\unimarc_field_225a.pl cataloguing\value_builder\unimarc_field_4XX.pl circ\circulation.pl members\memberentry.pl reports\acquisitions_stats.pl reports\borrowers_out.pl reports\borrowers_stats.pl reports\catalogue_stats.pl reports\cat_issues_top.pl reports\guided_reports.pl reports\issues_avg_stats.pl reports\issues_by_borrower_category.plugin reports\issues_stats.pl reports\itemtypes.plugin reports\reserves_stats.pl reports\serials_stats.pl reserve\request.pl tools\batchMod.pl Marc Am 09.01.2013 00:30, schrieb Chris Cormack: > > > Bernardo Gonzalez Kriegel wrote: > >> Hi, >> I've been studying the code to hopefully find (and eventually fix) >> all occurrences of code to display an ordered list of branches, >> to close Bug 5634 [1] >> >> There is a zoo of different versions, so I have some questions: >> >> 1) It's desirable to change the code to use GetBranchesLoop() >> whenever possible, or only fix the sort order in place? >> >> 2) Some solutions use CGI::scrolling_list() to draw the drop down list. >> This simplifies the template, but is more code in the script. >> Which version do you think is better? > > CGI::scrolling_list should be removed wherever it is found, it renders the contents untranslatable. > > Chris >> >> Regards, >> Bernardo >> >> [1] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5634 > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > From mjr at phonecoop.coop Wed Jan 9 15:12:56 2013 From: mjr at phonecoop.coop (MJ Ray) Date: Wed, 09 Jan 2013 14:12:56 +0000 Subject: [Koha-devel] Old bugs to check Message-ID: Would you check some of these rather old bugs to suggest what to do, please? Maybe some can be RESOLVED FIXED by now or need a question. Ideally, tell irc.oftc.net #koha know that you're looking at a bug. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3707 Add system preference for customization of the OPAC login page http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3162 Authority subfileds definitions and Show/Show Collapsed/Hide option http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3529 Import of items with non-existent branch code fails w/o explaination http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3473 Specify time span for changing claims returned and long overdue to lost http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5438 Holds managed in circ rules http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2499 Improvement on text wrapping algorithm needed http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1356 Lose original search term when select "More options" http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2096 Label sources for OPAC descriptions http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3476 Predefined fee types http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4171 overduerules.pl needs an overhaul http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5512 Display Published Date with Received Date http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3530 Auto label batch generation feature of the bulk import tool fails http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4397 display problems (umlauts, ?) with scan index in advanced search http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2647 Make Patron Reading History be Paginated http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3474 Handling of and report for expired or cancelled holds, display expiration dates http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2878 cloud-kw.pl: should use HTML template http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4439 two acq webservices should use C4::Service http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4971 Planning types not translatable in acq From paul.a at aandc.org Wed Jan 9 18:25:16 2013 From: paul.a at aandc.org (Paul) Date: Wed, 09 Jan 2013 12:25:16 -0500 Subject: [Koha-devel] "Damaged" values In-Reply-To: <1328738898.26658.14.camel@zarathud> References: <5.2.1.1.2.20120208143210.0196a030@stormy.ca> <5.2.1.1.2.20120208143210.0196a030@stormy.ca> Message-ID: <5.2.1.1.2.20130109101246.04dc5310@localhost> Happy New Year to all, Finally made 3.8.5 public at but have not really "published the news" yet. One glitch that I would really like to re-address is the "damaged" values. Problem: example at -- red label "Reference only: Damaged (1)" when the book is "Normal wear", but "Normal wear" is properly shown in the item's "MARC detail." In 3.6.x (with Robin Sheat's kind assistance, see below) we successfully used additional auth values of "damaged" 2 Unknown Condition not stated 1 Damaged Some damage noted 0 Not damaged Not damaged -1 Used book Used book -2 Normal wear Normal wear but in 3.8 the "fix" is no longer functional. In 3.6 it was a fairly trivial change to detail.pl 'if ($item->{damaged})' using >0 -- but a grep in 3.8.4/5 shows that this phrase has disappeared (and I've spent some time looking for "damaged" across Perl, xslt, inc, tt, etc. with no luck.) Could some kind soul please suggest where I start looking for a solution? Thanks in advance and best regards, Paul At 11:08 AM 2/9/2012 +1300, Robin Sheat wrote: >Paul schreef op wo 08-02-2012 om 14:37 [-0500]: > > I assume (maybe incorrectly) that the value of "damaged" is read by > > detail.pl starting line 196: > > > > if ($item->{damaged}) { > >So the nutshell version of what's going on: > >The Perl line above says essentially "if the damaged value != 0, >then..." > >So by having "normal wear" at 3, it thinks its damaged. My suggestion to >change this would perhaps to be to change that line so that it's > >if ($item->{damaged} > 0) { > >and then you could set 'normal wear' to -1 and it wouldn't show as >damaged. > >-- >Robin Sheat >Catalyst IT Ltd. >??? +64 4 803 2204 >GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D > >_______________________________________________ >Koha-devel mailing list >Koha-devel at 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. and From waqar.azeem at itcompletes.com Thu Jan 10 14:25:14 2013 From: waqar.azeem at itcompletes.com (Waqar Azeem) Date: Thu, 10 Jan 2013 18:25:14 +0500 Subject: [Koha-devel] My Zebra Indexing with ICU option is not working Message-ID: After enabling the ICU option manually, it's not working for my huge data until I deleted the most of the biblio records. I tried following links/articles to configure ICU: ? http://www.scribd.com/doc/45190333/ICU-Support-in-Zebra ? And http://kohageek.pbworks.com/w/page/31484686/zebra%20configuration%20for%20regional%20language%20searching Then only difference was, I modified to blank instead of . As I am not sure what to do with locale for other languages So, 1 - I am getting these warining? Although I have already renamed my default.idx located at /home/koha/koha-dev/etc/zebradb/etc (i hope this is the right location) ==================== REINDEXING zebra ==================== 12:22:45-10/01 zebraidx(2057) [warn] Unknown register type: 0 12:22:45-10/01 zebraidx(2057) [warn] Unknown register type: n 12:22:45-10/01 zebraidx(2057) [warn] Unknown register type: y 12:22:45-10/01 zebraidx(2057) [warn] Unknown register type: d 2 - Right after that I have this warning [warn] previous transaction didn't reach commit 3 - I deleted the records upto just 9000. Now zebra started to index other languages. Why it is working only on this small set of data? Do i need to define any escape sequence somewhere for some special characters. I am using 3.08.00.001 on Debean VM I hope this is the right command to re-index. koha at koha:~$ export PERL5LIB=/home/koha/kohaclone/ koha at koha:~$ export KOHA_CONF=/home/koha/koha-dev/etc/koha-conf.xml koha at koha:~$ /home/koha/kohaclone/misc/migration_tools/rebuild_zebra.pl -b -r -v -- Thanks & Best Regards, Waqar Azeem -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: default.idx.backup Type: application/octet-stream Size: 1140 bytes Desc: not available URL: From jcamins at cpbibliography.com Thu Jan 10 14:41:00 2013 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Thu, 10 Jan 2013 08:41:00 -0500 Subject: [Koha-devel] My Zebra Indexing with ICU option is not working In-Reply-To: References: Message-ID: Waqar, After enabling the ICU option manually, it's not working for my huge data > until I deleted the most of the biblio records. > > Then only difference was, I modified to blank locale=""> instead of . As I am not sure > what to do with locale for other languages > You cannot not have a locale, so far as I know. Leave it as locale="en" if you don't know what locale you want. So, > > 1 - I am getting these warining? Although I have already renamed my > default.idx located at /home/koha/koha-dev/etc/zebradb/etc (i hope > this is the right location) > I'm not sure why you're talking about renaming default.idx, but you should not be. default.idx is required whether you are using ICU or not. You just have to adjust whether it is using an icuchain or charmap file. ==================== > REINDEXING zebra > ==================== > 12:22:45-10/01 zebraidx(2057) [warn] Unknown register type: 0 > 12:22:45-10/01 zebraidx(2057) [warn] Unknown register type: n > 12:22:45-10/01 zebraidx(2057) [warn] Unknown register type: y > 12:22:45-10/01 zebraidx(2057) [warn] Unknown register type: d > > 2 - Right after that I have this warning > > [warn] previous transaction didn't reach commit > That will be because either A) there was a very corrupted record or (more likely) B) the lack of a default.idx file is giving Zebra conniptions. > 3 - I deleted the records upto just 9000. Now zebra started to index other > languages. Why it is working only on this small set of data? Do i need to > define any escape sequence somewhere for some special characters. > I had problems using ICU indexing for datasets larger than ~400k. I believe the problem was a corrupted record, but with 450k records I couldn't be bothered to track down which record it was. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins at cpbibliography.com (web) http://www.cpbibliography.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgkriegel at gmail.com Fri Jan 11 18:08:25 2013 From: bgkriegel at gmail.com (Bernardo Gonzalez Kriegel) Date: Fri, 11 Jan 2013 14:08:25 -0300 Subject: [Koha-devel] Failed unit test Message-ID: Hello, just trying to do a sign-off following http://wiki.koha-community.org/wiki/Sign_off_on_patches It's ok that some test of prove t/ prove t/db_dependent prove xt/author fail even in a clean master? Regards, Bernardo -- Bernardo Gonzalez Kriegel bgkriegel at gmail.com From jcamins at cpbibliography.com Fri Jan 11 18:12:51 2013 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Fri, 11 Jan 2013 12:12:51 -0500 Subject: [Koha-devel] Failed unit test In-Reply-To: References: Message-ID: Bernardo, It's ok that some test of > > prove t/ > prove t/db_dependent > prove xt/author > > fail even in a clean master? > No unit tests should be failing on master. However, since they're passing on both jenkins and my server it is probably just a data issue, which means you can probably sign off if no additional tests fail after applying the patch, and hop on #koha when you have a chance so we can figure out why some of the tests are failing for you and fix it. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins at cpbibliography.com (web) http://www.cpbibliography.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Fri Jan 11 18:19:19 2013 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 11 Jan 2013 18:19:19 +0100 Subject: [Koha-devel] Failed unit test In-Reply-To: References: Message-ID: <50F04997.4040504@biblibre.com> Le 11/01/2013 18:08, Bernardo Gonzalez Kriegel a ?crit : > Hello, > just trying to do a sign-off following > http://wiki.koha-community.org/wiki/Sign_off_on_patches > > It's ok that some test of > > prove t/ > prove t/db_dependent those one probably fail because you don't have the expected datas. > prove xt/author > fail even in a clean master? OTOH: signing-off is checking that the feature works fine. It's the QA team that will be in charge to check unit tests. (Of course, if a patch contains a unit test itself, you should not signoff until you've successfully run it ;-) ) HTH -- Paul POULAIN - BibLibre http://www.biblibre.com Free & Open Source Softwares for libraries Koha, Drupal, Piwik, Jasper From jcamins at cpbibliography.com Fri Jan 11 18:37:54 2013 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Fri, 11 Jan 2013 12:37:54 -0500 Subject: [Koha-devel] Failed unit test In-Reply-To: <50F04997.4040504@biblibre.com> References: <50F04997.4040504@biblibre.com> Message-ID: Paul, OTOH: signing-off is checking that the feature works fine. It's the QA > team that will be in charge to check unit tests. > (Of course, if a patch contains a unit test itself, you should not > signoff until you've successfully run it ;-) ) > Signing off is both checking that a feature works and -- hopefully -- considering whether there are any bigger problems with it, such as regressions, to the extent that the developer is able to do this. Unit tests provide an easy way to test for regressions, which is why it's a good idea to run them -- if not all of them, at least the relevant ones -- while signing off. Obviously as RM I do not have the power to mandate that everyone must run unit tests before signing off, nor would I want to, but I will say that the more thorough the sign off, the more likely it is that I will spend time on a patch. Patches with only a perfunctory sign off are more likely to trigger my "one strike" rule (that's the rule that says the first problem I encounter with a patch, no matter how minor, can get the patch failed). The QA team should also be running unit tests, of course, but the point of the sign off/QA divide is that we want more eyes reviewing patches before they go in. If the developer who signs off is running unit tests, I can feel pretty confident that they didn't just add a "Signed-off-by" line before uploading a patch. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins at cpbibliography.com (web) http://www.cpbibliography.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgkriegel at gmail.com Fri Jan 11 19:30:16 2013 From: bgkriegel at gmail.com (Bernardo Gonzalez Kriegel) Date: Fri, 11 Jan 2013 15:30:16 -0300 Subject: [Koha-devel] Failed unit test In-Reply-To: References: <50F04997.4040504@biblibre.com> Message-ID: Paul and Jared, It seems that my 'clean' master was not that clean. I do a new clone, and the errors I found on master can be attributed to some missing sample data and a problem I have with Test::Pod::Spelling So now I know what to expect. Anyway, I was just trying to obey the rules. Thank you both, Bernardo -- Bernardo Gonzalez Kriegel bgkriegel at gmail.com On Fri, Jan 11, 2013 at 2:37 PM, Jared Camins-Esakov wrote: > Paul, > >> OTOH: signing-off is checking that the feature works fine. It's the QA >> team that will be in charge to check unit tests. >> (Of course, if a patch contains a unit test itself, you should not >> signoff until you've successfully run it ;-) ) > > > Signing off is both checking that a feature works and -- hopefully -- > considering whether there are any bigger problems with it, such as > regressions, to the extent that the developer is able to do this. Unit tests > provide an easy way to test for regressions, which is why it's a good idea > to run them -- if not all of them, at least the relevant ones -- while > signing off. Obviously as RM I do not have the power to mandate that > everyone must run unit tests before signing off, nor would I want to, but I > will say that the more thorough the sign off, the more likely it is that I > will spend time on a patch. Patches with only a perfunctory sign off are > more likely to trigger my "one strike" rule (that's the rule that says the > first problem I encounter with a patch, no matter how minor, can get the > patch failed). > > The QA team should also be running unit tests, of course, but the point of > the sign off/QA divide is that we want more eyes reviewing patches before > they go in. If the developer who signs off is running unit tests, I can feel > pretty confident that they didn't just add a "Signed-off-by" line before > uploading a patch. > > Regards, > Jared > > -- > Jared Camins-Esakov > Bibliographer, C & P Bibliography Services, LLC > (phone) +1 (917) 727-3445 > (e-mail) jcamins at cpbibliography.com > (web) http://www.cpbibliography.com/ > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ From gmc at esilibrary.com Fri Jan 11 19:36:29 2013 From: gmc at esilibrary.com (Galen Charlton) Date: Fri, 11 Jan 2013 10:36:29 -0800 Subject: [Koha-devel] Failed unit test In-Reply-To: References: <50F04997.4040504@biblibre.com> Message-ID: Hi, On Fri, Jan 11, 2013 at 9:37 AM, Jared Camins-Esakov < jcamins at cpbibliography.com> wrote: > Signing off is both checking that a feature works and -- hopefully -- > considering whether there are any bigger problems with it, such as > regressions, to the extent that the developer is able to do this. Unit > tests provide an easy way to test for regressions, which is why it's a good > idea to run them -- if not all of them, at least the relevant ones -- while > signing off. Obviously as RM I do not have the power to mandate that > everyone must run unit tests before signing off, nor would I want to, but I > will say that the more thorough the sign off, the more likely it is that I > will spend time on a patch. Patches with only a perfunctory sign off are > more likely to trigger my "one strike" rule (that's the rule that says the > first problem I encounter with a patch, no matter how minor, can get the > patch failed). > > The QA team should also be running unit tests, of course, but the point of > the sign off/QA divide is that we want more eyes reviewing patches before > they go in. If the developer who signs off is running unit tests, I can > feel pretty confident that they didn't just add a "Signed-off-by" line > before uploading a patch. > I cannot give this enough +1s. QA *must* be considered the responsibility of everybody who regularly submits patches to Koha, not just the QA team. I consider making sure that the tests pass if you submit a patch or if you sign off on one to be the *bare minimum* of what we should expect of ourselves. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnighswonger at foundations.edu Fri Jan 11 19:45:11 2013 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Fri, 11 Jan 2013 13:45:11 -0500 Subject: [Koha-devel] Failed unit test In-Reply-To: References: <50F04997.4040504@biblibre.com> Message-ID: Many +1s here as well. Kind Regards, Chris On Fri, Jan 11, 2013 at 1:36 PM, Galen Charlton wrote: > Hi, > > On Fri, Jan 11, 2013 at 9:37 AM, Jared Camins-Esakov < > jcamins at cpbibliography.com> wrote: > >> Signing off is both checking that a feature works and -- hopefully -- >> considering whether there are any bigger problems with it, such as >> regressions, to the extent that the developer is able to do this. Unit >> tests provide an easy way to test for regressions, which is why it's a good >> idea to run them -- if not all of them, at least the relevant ones -- while >> signing off. Obviously as RM I do not have the power to mandate that >> everyone must run unit tests before signing off, nor would I want to, but I >> will say that the more thorough the sign off, the more likely it is that I >> will spend time on a patch. Patches with only a perfunctory sign off are >> more likely to trigger my "one strike" rule (that's the rule that says the >> first problem I encounter with a patch, no matter how minor, can get the >> patch failed). >> >> The QA team should also be running unit tests, of course, but the point >> of the sign off/QA divide is that we want more eyes reviewing patches >> before they go in. If the developer who signs off is running unit tests, I >> can feel pretty confident that they didn't just add a "Signed-off-by" line >> before uploading a patch. >> > > I cannot give this enough +1s. QA *must* be considered the responsibility > of everybody who regularly submits patches to Koha, not just the QA team. > I consider making sure that the tests pass if you submit a patch or if you > sign off on one to be the *bare minimum* of what we should expect of > ourselves. > > Regards, > > Galen > -- > Galen Charlton > Manager of Implementation > Equinox Software, Inc. / The Open Source Experts > email: gmc at esilibrary.com > direct: +1 770-709-5581 > cell: +1 404-984-4366 > skype: gmcharlt > web: http://www.esilibrary.com/ > Supporting Koha and Evergreen: http://koha-community.org & > http://evergreen-ils.org > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Katrin.Fischer at bsz-bw.de Fri Jan 11 19:56:10 2013 From: Katrin.Fischer at bsz-bw.de (Fischer, Katrin) Date: Fri, 11 Jan 2013 19:56:10 +0100 Subject: [Koha-devel] Failed unit test References: <50F04997.4040504@biblibre.com> Message-ID: <028B1A54D03E7B4482CDCA4EC8F06BFD0162693F@Bodensee.bsz-bw.de> +1 :) -----Original Message----- From: koha-devel-bounces at lists.koha-community.org on behalf of Chris Nighswonger Sent: Fri 11.01.2013 19:45 To: Galen Charlton Cc: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Failed unit test Many +1s here as well. Kind Regards, Chris On Fri, Jan 11, 2013 at 1:36 PM, Galen Charlton wrote: > Hi, > > On Fri, Jan 11, 2013 at 9:37 AM, Jared Camins-Esakov < > jcamins at cpbibliography.com> wrote: > >> Signing off is both checking that a feature works and -- hopefully -- >> considering whether there are any bigger problems with it, such as >> regressions, to the extent that the developer is able to do this. Unit >> tests provide an easy way to test for regressions, which is why it's a good >> idea to run them -- if not all of them, at least the relevant ones -- while >> signing off. Obviously as RM I do not have the power to mandate that >> everyone must run unit tests before signing off, nor would I want to, but I >> will say that the more thorough the sign off, the more likely it is that I >> will spend time on a patch. Patches with only a perfunctory sign off are >> more likely to trigger my "one strike" rule (that's the rule that says the >> first problem I encounter with a patch, no matter how minor, can get the >> patch failed). >> >> The QA team should also be running unit tests, of course, but the point >> of the sign off/QA divide is that we want more eyes reviewing patches >> before they go in. If the developer who signs off is running unit tests, I >> can feel pretty confident that they didn't just add a "Signed-off-by" line >> before uploading a patch. >> > > I cannot give this enough +1s. QA *must* be considered the responsibility > of everybody who regularly submits patches to Koha, not just the QA team. > I consider making sure that the tests pass if you submit a patch or if you > sign off on one to be the *bare minimum* of what we should expect of > ourselves. > > Regards, > > Galen > -- > Galen Charlton > Manager of Implementation > Equinox Software, Inc. / The Open Source Experts > email: gmc at esilibrary.com > direct: +1 770-709-5581 > cell: +1 404-984-4366 > skype: gmcharlt > web: http://www.esilibrary.com/ > Supporting Koha and Evergreen: http://koha-community.org & > http://evergreen-ils.org > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielg.koha at gmail.com Fri Jan 11 21:34:11 2013 From: danielg.koha at gmail.com (Daniel Grobani) Date: Fri, 11 Jan 2013 12:34:11 -0800 Subject: [Koha-devel] Call for news for the January newsletter Message-ID: Dear Koha kommunitarians, I'm harvesting news for this month's newsletter. Please send me by the 20th anything you think your fellow community members might like to know about. "News" can be as short as a sentence or as long as a paper. I especially encourage you to send me a line or two for the gossip/society column about what you're currently working on. And if you know of a go-live not announced on the list, please be sure to let me know about it. Thanks, Daniel Grobani -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcamins at cpbibliography.com Sun Jan 13 15:29:39 2013 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Sun, 13 Jan 2013 09:29:39 -0500 Subject: [Koha-devel] RM and QA roles (important!) Message-ID: Good morning. I thought about using the subject "In search of lost time," but I decided that was a bad idea given how few people actually manage to get through Proust. I am writing with a discussion question for the community. According to the dashboard, at the moment we have 120 bugs with the status "Needs signoff" (25% of these are classified as "bugs" instead of "enhancements" or "new features") and 94 bugs with the status "Signed off" (50% bugs). 2 bugs have the status "Passed QA" and are waiting for feedback from their authors before I push them. There are two lessons we can learn from these numbers: 1) if everyone currently involved with Koha made a commitment to test two patches in January, we could get through the backlog for 3.12 2) we have a QA bottleneck. Please consider lesson 1, but this e-mail is actually about lesson 2. QA is an inherently time-consuming process, and the pool for QAers is much smaller than that for signing off. I expect that as we approach the deadlines for 3.12 the number of bugs awaiting QA will decrease. Unfortunately, the amount of time I have to deal with those bugs will not increase, even though I am spending somewhat less time than I planned dealing with RM duties this month. So, I come to the community with a question: what would people think of me using that time to QA bugs (as opposed to enhancements/new features) that I was not involved in the authorship or signing off of? I would prefer not to do this, but after a month and a half as RM it seems to me that this might be in the best interest of the community and the best way to release a stable and feature-full 3.12. QAing signed off patches would naturally take a much lower priority for me than addressing patches that have already passed QA, but every patch I QA is a patch that our overworked QA team does not have to QA. Thoughts? Also, on a somewhat-related subject, I will be away from January 25-February 4. Keep that in mind if you intend to have any questions that only the RM can answer at the end of the month. Regards, Jared Camins-Esakov -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins at cpbibliography.com (web) http://www.cpbibliography.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.m.hall at gmail.com Sun Jan 13 16:10:46 2013 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Sun, 13 Jan 2013 10:10:46 -0500 Subject: [Koha-devel] RM and QA roles (important!) In-Reply-To: References: Message-ID: I certainly see no problem with this course of action. It sounds like time well spent to me! Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Sun, Jan 13, 2013 at 9:29 AM, Jared Camins-Esakov < jcamins at cpbibliography.com> wrote: > Good morning. > > I thought about using the subject "In search of lost time," but I decided > that was a bad idea given how few people actually manage to get through > Proust. > > I am writing with a discussion question for the community. According to > the dashboard, at the moment we have 120 bugs with the status "Needs > signoff" (25% of these are classified as "bugs" instead of "enhancements" > or "new features") and 94 bugs with the status "Signed off" (50% bugs). 2 > bugs have the status "Passed QA" and are waiting for feedback from their > authors before I push them. > > There are two lessons we can learn from these numbers: > 1) if everyone currently involved with Koha made a commitment to test two > patches in January, we could get through the backlog for 3.12 > 2) we have a QA bottleneck. > > Please consider lesson 1, but this e-mail is actually about lesson 2. QA > is an inherently time-consuming process, and the pool for QAers is much > smaller than that for signing off. I expect that as we approach the > deadlines for 3.12 the number of bugs awaiting QA will decrease. > Unfortunately, the amount of time I have to deal with those bugs will not > increase, even though I am spending somewhat less time than I planned > dealing with RM duties this month. So, I come to the community with a > question: what would people think of me using that time to QA bugs (as > opposed to enhancements/new features) that I was not involved in the > authorship or signing off of? I would prefer not to do this, but after a > month and a half as RM it seems to me that this might be in the best > interest of the community and the best way to release a stable and > feature-full 3.12. QAing signed off patches would naturally take a much > lower priority for me than addressing patches that have already passed QA, > but every patch I QA is a patch that our overworked QA team does not have > to QA. > > Thoughts? > > Also, on a somewhat-related subject, I will be away from January > 25-February 4. Keep that in mind if you intend to have any questions that > only the RM can answer at the end of the month. > > Regards, > Jared Camins-Esakov > > -- > Jared Camins-Esakov > Bibliographer, C & P Bibliography Services, LLC > (phone) +1 (917) 727-3445 > (e-mail) jcamins at cpbibliography.com > (web) http://www.cpbibliography.com/ > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisc at catalyst.net.nz Sun Jan 13 18:46:06 2013 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Mon, 14 Jan 2013 06:46:06 +1300 Subject: [Koha-devel] RM and QA roles (important!) In-Reply-To: References: Message-ID: I'd obviously prefer not to have one set of eyes less. But if it is just bug fixes to help reduce the bottleneck then I will suspend my objections :) Chris Jared Camins-Esakov wrote: >Good morning. > >I thought about using the subject "In search of lost time," but I >decided >that was a bad idea given how few people actually manage to get through >Proust. > >I am writing with a discussion question for the community. According to >the >dashboard, at the moment we have 120 bugs with the status "Needs >signoff" >(25% of these are classified as "bugs" instead of "enhancements" or >"new >features") and 94 bugs with the status "Signed off" (50% bugs). 2 bugs >have >the status "Passed QA" and are waiting for feedback from their authors >before I push them. > >There are two lessons we can learn from these numbers: >1) if everyone currently involved with Koha made a commitment to test >two >patches in January, we could get through the backlog for 3.12 >2) we have a QA bottleneck. > >Please consider lesson 1, but this e-mail is actually about lesson 2. >QA is >an inherently time-consuming process, and the pool for QAers is much >smaller than that for signing off. I expect that as we approach the >deadlines for 3.12 the number of bugs awaiting QA will decrease. >Unfortunately, the amount of time I have to deal with those bugs will >not >increase, even though I am spending somewhat less time than I planned >dealing with RM duties this month. So, I come to the community with a >question: what would people think of me using that time to QA bugs (as >opposed to enhancements/new features) that I was not involved in the >authorship or signing off of? I would prefer not to do this, but after >a >month and a half as RM it seems to me that this might be in the best >interest of the community and the best way to release a stable and >feature-full 3.12. QAing signed off patches would naturally take a much >lower priority for me than addressing patches that have already passed >QA, >but every patch I QA is a patch that our overworked QA team does not >have >to QA. > >Thoughts? > >Also, on a somewhat-related subject, I will be away from January >25-February 4. Keep that in mind if you intend to have any questions >that >only the RM can answer at the end of the month. > >Regards, >Jared Camins-Esakov > >-- >Jared Camins-Esakov >Bibliographer, C & P Bibliography Services, LLC >(phone) +1 (917) 727-3445 >(e-mail) jcamins at cpbibliography.com >(web) http://www.cpbibliography.com/ > > >------------------------------------------------------------------------ > >_______________________________________________ >Koha-devel mailing list >Koha-devel at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Sun Jan 13 19:19:23 2013 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Sun, 13 Jan 2013 18:19:23 +0000 Subject: [Koha-devel] RM and QA roles (important!) In-Reply-To: References: , Message-ID: <809BE39CD64BFD4EB9036172EBCCFA310E1ACB71@S-MAIL-1B.rijksmuseum.intra> +1 from me Note that we did so too with Paul as RM. Author, signer and RM make at least three sets of eyes. Marcel ________________________________ Van: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] namens Chris Cormack [chrisc at catalyst.net.nz] Verzonden: zondag 13 januari 2013 18:46 To: Jared Camins-Esakov; koha-devel at lists.koha-community.org Onderwerp: Re: [Koha-devel] RM and QA roles (important!) I'd obviously prefer not to have one set of eyes less. But if it is just bug fixes to help reduce the bottleneck then I will suspend my objections :) Chris Jared Camins-Esakov wrote: Good morning. I thought about using the subject "In search of lost time," but I decided that was a bad idea given how few people actually manage to get through Proust. I am writing with a discussion question for the community. According to the dashboard, at the moment we have 120 bugs with the status "Needs signoff" (25% of these are classified as "bugs" instead of "enhancements" or "new features") and 94 bugs with the status "Signed off" (50% bugs). 2 bugs have the status "Passed QA" and are waiting for feedback from their authors before I push them. There are two lessons we can learn from these numbers: 1) if everyone currently involved with Koha made a commitment to test two patches in January, we could get through the backlog for 3.12 2) we have a QA bottleneck. Please consider lesson 1, but this e-mail is actually about lesson 2. QA is an inherently time-consuming process, and the pool for QAers is much smaller than that for signing off. I expect that as we approach the deadlines for 3.12 the number of bugs awaiting QA will decrease. Unfortunately, the amount of time I have to deal with those bugs will not increase, even though I am spending somewhat less time than I planned dealing with RM duties this month. So, I come to the community with a question: what would people think of me using that time to QA bugs (as opposed to enhancements/new features) that I was not involved in the authorship or signing off of? I would prefer not to do this, but after a month and a half as RM it seems to me that this might be in the best interest of the community and the best way to release a stable and feature-full 3.12. QAing signed off patches wou ld naturally take a much lower priority for me than addressing patches that have already passed QA, but every patch I QA is a patch that our overworked QA team does not have to QA. Thoughts? Also, on a somewhat-related subject, I will be away from January 25-February 4. Keep that in mind if you intend to have any questions that only the RM can answer at the end of the month. Regards, Jared Camins-Esakov -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins at cpbibliography.com (web) http://www.cpbibliography.com/ ________________________________ Koha-devel mailing list Koha-devel at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nengard at gmail.com Sun Jan 13 20:06:27 2013 From: nengard at gmail.com (Nicole Engard) Date: Sun, 13 Jan 2013 14:06:27 -0500 Subject: [Koha-devel] RM and QA roles (important!) In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA310E1ACB71@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA310E1ACB71@S-MAIL-1B.rijksmuseum.intra> Message-ID: +1 from me. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Katrin.Fischer.83 at web.de Mon Jan 14 07:48:14 2013 From: Katrin.Fischer.83 at web.de (Katrin Fischer) Date: Mon, 14 Jan 2013 07:48:14 +0100 Subject: [Koha-devel] RM and QA roles (important!) In-Reply-To: References: Message-ID: <50F3AA2E.7010203@web.de> I hope now that holidays are over and everyone is back to work we will be able to reduce the bottleneck. That said I see no problem Jared QAing bug fixes, although I think it would be better if we can make use of his time for pushing patches instead :) Katrin Am 13.01.2013 18:46, schrieb Chris Cormack: > I'd obviously prefer not to have one set of eyes less. But if it is just > bug fixes to help reduce the bottleneck then I will suspend my > objections :) > > Chris > > Jared Camins-Esakov wrote: > > Good morning. > > I thought about using the subject "In search of lost time," but I > decided that was a bad idea given how few people actually manage to > get through Proust. > > I am writing with a discussion question for the community. According > to the dashboard, at the moment we have 120 bugs with the status > "Needs signoff" (25% of these are classified as "bugs" instead of > "enhancements" or "new features") and 94 bugs with the status > "Signed off" (50% bugs). 2 bugs have the status "Passed QA" and are > waiting for feedback from their authors before I push them. > > There are two lessons we can learn from these numbers: > 1) if everyone currently involved with Koha made a commitment to > test two patches in January, we could get through the backlog for 3.12 > 2) we have a QA bottleneck. > > Please consider lesson 1, but this e-mail is actually about lesson > 2. QA is an inherently time-consuming process, and the pool for > QAers is much smaller than that for signing off. I expect that as we > approach the deadlines for 3.12 the number of bugs awaiting QA will > decrease. Unfortunately, the amount of time I have to deal with > those bugs will not increase, even though I am spending somewhat > less time than I planned dealing with RM duties this month. So, I > come to the community with a question: what would people think of me > using that time to QA bugs (as opposed to enhancements/new features) > that I was not involved in the authorship or signing off of? I would > prefer not to do this, but after a month and a half as RM it seems > to me that this might be in the best interest of the community and > the best way to release a stable and feature-full 3.12. QAing signed > off patches wou ld naturally take a much lower priority for me than > addressing patches that have already passed QA, but every patch I QA > is a patch that our overworked QA team does not have to QA. > > Thoughts? > > Also, on a somewhat-related subject, I will be away from January > 25-February 4. Keep that in mind if you intend to have any questions > that only the RM can answer at the end of the month. > > Regards, > Jared Camins-Esakov > > -- > Jared Camins-Esakov > Bibliographer, C & P Bibliography Services, LLC > (phone) +1 (917) 727-3445 > (e-mail) jcamins at cpbibliography.com > (web) http://www.cpbibliography.com/ > > ------------------------------------------------------------------------ > > Koha-devel mailing list > Koha-devel at 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/ > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > From paul.poulain at biblibre.com Mon Jan 14 09:36:57 2013 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 14 Jan 2013 09:36:57 +0100 Subject: [Koha-devel] RM and QA roles (important!) In-Reply-To: References: Message-ID: <50F3C3A9.7080000@biblibre.com> Le 13/01/2013 15:29, Jared Camins-Esakov a ?crit : > Please consider lesson 1, but this e-mail is actually about lesson 2. QA > is an inherently time-consuming process, and the pool for QAers is much > smaller than that for signing off. I expect that as we approach the > deadlines for 3.12 the number of bugs awaiting QA will decrease. Hi Jared, This morning, while I was under my shower, I was thinking of this problem. I can't dedicate as much time as I'd like (I've a business to run, hdl has left now). Jonathan does a great job, but we (BibLibre) can't do everything. So I'm very happy with this mail !!! lesson 1= Everybody should also realize that having patches waiting for signoff for more than 3 months results in rebase needed. And rebase needed result in time consuming, that could be used elsewhere. Last week, the 10 oldest bugs where all enhancements waiting for more than 4 months. 8 where from BibLibre, 5 have been rebased, Julian spent around 6 hours to do that. Hours that could have been used to signoff someone else patch. I don't know what to do with this situation, I just can say that it's unefficient. If someone has a suggestion... (I made some, months/years ago. You know my opinion, I know many of you disagree, but any proposal would be carefully examined by me, for sure !) lesson 1 (again)= I've started last week to send an email to some french librarians that were at the hackfest, and have a personal sandbox (that BibLibre setup for them). In this mail, I point 10 of the oldest patches that they could signoff. I hope it will produce some results. I'll do that for at least 2 months, then see if the effort produces some effect. lesson 2= +1 to have you QAing patches, of course. That's how I made it last year, I think 3.10 was pretty stable. I'm sure you'll be wise enough to know which patch would be worth having another set of eyes, and ask the QA team. PS: I see on the signed-off list that 1/3 of patches don't have a complexity set. That's a shame, because "trivial" and "small patches" could be QAed by you fist. -- Paul POULAIN - BibLibre http://www.biblibre.com Free & Open Source Softwares for libraries Koha, Drupal, Piwik, Jasper From chris at bigballofwax.co.nz Tue Jan 15 05:25:29 2013 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Tue, 15 Jan 2013 17:25:29 +1300 Subject: [Koha-devel] String freeze for 3.8.x and 3.10.x Message-ID: Hi All Tomorrow is the start of the string freeze for 3.8.9 and 3.10.2, Ruth could you please update the po files accordingly. Chris From mjr at phonecoop.coop Tue Jan 15 13:21:19 2013 From: mjr at phonecoop.coop (MJ Ray) Date: Tue, 15 Jan 2013 12:21:19 +0000 Subject: [Koha-devel] Old bugs to check Message-ID: Would you check some of these rather old bugs to suggest what to do, please? Maybe some can be RESOLVED FIXED by now or need a question. Ideally, tell irc.oftc.net #koha know that you're looking at a bug. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4120 WebBasedSelfCheck http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3225 patrons with no checkouts report - patron names not displaying http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4910 Debian Packaging does not start Apache (on Ubuntu Lucid) http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5552 circ dates in the past http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4126 bulkmarcimport.pl allows -b and -a to be specified simultaneously http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3474 Handling of and report for expired or cancelled holds, display expiration dates http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3134 Ability to selelct multiple reports to delete at once http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4234 Automatic transfer shouldn't take precedence over a hold transit http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5469 alphabetize frameworks http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4234 Automatic transfer shouldn't take precedence over a hold transit http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3474 Handling of and report for expired or cancelled holds, display expiration dates http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4202 Improve international currency and exchange support http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2283 Poor use of "Not Found" redirect in response to corrupt MARC record http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4848 Ability for patrons to create their own accounts http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3327 rebuild_zebra.pl doesn't index authorities in XML http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3068 Auth.pm: IP address matching overly generous http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5291 Purchase suggestion not working http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2954 Holds queue report should show date/time of last update From mathieu.saby at univ-rennes2.fr Wed Jan 16 12:39:56 2013 From: mathieu.saby at univ-rennes2.fr (Mathieu Saby) Date: Wed, 16 Jan 2013 12:39:56 +0100 Subject: [Koha-devel] changing a status to "need signed off'" Message-ID: <50F6918C.7060306@univ-rennes2.fr> Hello I made a followup for http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8946, so I want to mark it "need signed-off" but I can't. The bug was already pushed to master. Maybe should I have made a new bug for my followup ? Regards, M. Saby Rennes 2 University. -- 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 at univ-rennes2.fr From jcamins at cpbibliography.com Wed Jan 16 14:16:35 2013 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Wed, 16 Jan 2013 08:16:35 -0500 Subject: [Koha-devel] changing a status to "need signed off'" In-Reply-To: <50F6918C.7060306@univ-rennes2.fr> References: <50F6918C.7060306@univ-rennes2.fr> Message-ID: Mathieu, I made a followup for http://bugs.koha-community.** > org/bugzilla3/show_bug.cgi?id=**8946, > so I want to mark it "need signed-off" but I can't. > The bug was already pushed to master. Maybe should I have made a new bug > for my followup ? > Yes please. The way to set the status back to "Needs signoff" is to reset it to "ASSIGNED" first, then switch it to "Needs signoff," but one of my new policies is that follow-ups must be done on new bugs once a patch has been pushed to master. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins at cpbibliography.com (web) http://www.cpbibliography.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.saby at univ-rennes2.fr Wed Jan 16 14:17:54 2013 From: mathieu.saby at univ-rennes2.fr (Mathieu Saby) Date: Wed, 16 Jan 2013 14:17:54 +0100 Subject: [Koha-devel] changing a status to "need signed off'" In-Reply-To: References: <50F6918C.7060306@univ-rennes2.fr> Message-ID: <50F6A882.8040505@univ-rennes2.fr> Jared Camins-Esakov a ?crit : > Mathieu, > > I made a followup for > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8946, so > I want to mark it "need signed-off" but I can't. > The bug was already pushed to master. Maybe should I have made a > new bug for my followup ? > > > Yes please. The way to set the status back to "Needs signoff" is to > reset it to "ASSIGNED" first, then switch it to "Needs signoff," but > one of my new policies is that follow-ups must be done on new bugs > once a patch has been pushed to master. Thank you Jared, I will do that way. M. Saby > > Regards, > Jared > > -- > Jared Camins-Esakov > Bibliographer, C & P Bibliography Services, LLC > (phone) +1 (917) 727-3445 > (e-mail) jcamins at cpbibliography.com > (web) http://www.cpbibliography.com/ -- 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 at univ-rennes2.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: From samuel.desseaux at ecp.fr Wed Jan 16 14:19:19 2013 From: samuel.desseaux at ecp.fr (Samuel Desseaux) Date: Wed, 16 Jan 2013 14:19:19 +0100 Subject: [Koha-devel] about records in koha pro Message-ID: <50F6A8D7.7090000@ecp.fr> Hi, I've a question of my colleagues. In the opac, when i'm looking for something, i've the results and when i choose one of the results, i can add a link to come back to the results and another link to the search example: i make a research and it gives the results http://koha.ecp.fr:8080/cgi-bin/koha/catalogue/search.pl?q=eau I choose one of the result and there, i 'd be able to see the next record which is in the list of results. Is it possible? I hope that you will understand my request. Best regards, samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: samuel_desseaux.vcf Type: text/x-vcard Size: 345 bytes Desc: not available URL: From mathieu.saby at univ-rennes2.fr Wed Jan 16 14:32:03 2013 From: mathieu.saby at univ-rennes2.fr (Mathieu Saby) Date: Wed, 16 Jan 2013 14:32:03 +0100 Subject: [Koha-devel] changing a status to "need signed off'" In-Reply-To: <50F6A882.8040505@univ-rennes2.fr> References: <50F6918C.7060306@univ-rennes2.fr> <50F6A882.8040505@univ-rennes2.fr> Message-ID: <50F6ABD3.4040005@univ-rennes2.fr> New bug made : http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9402 But how could I suppress the file I wrongly joined to BZ 8946 ? I don't know how to do that, except by sending a new file... M. Saby Mathieu Saby a ?crit : > > > Jared Camins-Esakov a ?crit : >> Mathieu, >> >> I made a followup for >> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8946, so >> I want to mark it "need signed-off" but I can't. >> The bug was already pushed to master. Maybe should I have made a >> new bug for my followup ? >> >> >> Yes please. The way to set the status back to "Needs signoff" is to >> reset it to "ASSIGNED" first, then switch it to "Needs signoff," but >> one of my new policies is that follow-ups must be done on new bugs >> once a patch has been pushed to master. > > Thank you Jared, I will do that way. > M. Saby >> >> Regards, >> Jared >> >> -- >> Jared Camins-Esakov >> Bibliographer, C & P Bibliography Services, LLC >> (phone) +1 (917) 727-3445 >> (e-mail) jcamins at cpbibliography.com >> (web) http://www.cpbibliography.com/ > > > -- > 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 at univ-rennes2.fr > > ------------------------------------------------------------------------ > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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 at univ-rennes2.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcamins at cpbibliography.com Wed Jan 16 14:52:49 2013 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Wed, 16 Jan 2013 08:52:49 -0500 Subject: [Koha-devel] changing a status to "need signed off'" In-Reply-To: <50F6ABD3.4040005@univ-rennes2.fr> References: <50F6918C.7060306@univ-rennes2.fr> <50F6A882.8040505@univ-rennes2.fr> <50F6ABD3.4040005@univ-rennes2.fr> Message-ID: Mathieu, New bug made : http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9402 > Thanks! > But how could I suppress the file I wrongly joined to BZ 8946 ? I don't > know how to do that, except by sending a new file... > If you click the details link next to the attachment, then click the "Edit details" link at the top, you can mark an attachment obsolete. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins at cpbibliography.com (web) http://www.cpbibliography.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.saby at univ-rennes2.fr Wed Jan 16 14:57:46 2013 From: mathieu.saby at univ-rennes2.fr (Mathieu Saby) Date: Wed, 16 Jan 2013 14:57:46 +0100 Subject: [Koha-devel] changing a status to "need signed off'" In-Reply-To: References: <50F6918C.7060306@univ-rennes2.fr> <50F6A882.8040505@univ-rennes2.fr> <50F6ABD3.4040005@univ-rennes2.fr> Message-ID: <50F6B1DA.9050801@univ-rennes2.fr> Re-thanks! This proves that a one-letter-bug can teach you a bunch of bugzilla tips... Jared Camins-Esakov a ?crit : > Mathieu, > > New bug made : > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9402 > > > Thanks! > > > But how could I suppress the file I wrongly joined to BZ 8946 ? I > don't know how to do that, except by sending a new file... > > > If you click the details link next to the attachment, then click the > "Edit details" link at the top, you can mark an attachment obsolete. > > Regards, > Jared > > -- > Jared Camins-Esakov > Bibliographer, C & P Bibliography Services, LLC > (phone) +1 (917) 727-3445 > (e-mail) jcamins at cpbibliography.com > (web) http://www.cpbibliography.com/ -- 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 at univ-rennes2.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnherz at gmail.com Wed Jan 16 23:17:14 2013 From: jnherz at gmail.com (John Herz) Date: Wed, 16 Jan 2013 16:17:14 -0600 Subject: [Koha-devel] About installation in OpenSuse 12.x Message-ID: Hello: I am looking for instalation instruction in OpenSuse 12.x if any have some experience, in the wiki only show without zebra configuring :( thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From samuel.desseaux at ecp.fr Wed Jan 16 23:20:40 2013 From: samuel.desseaux at ecp.fr (Samuel Desseaux) Date: Wed, 16 Jan 2013 23:20:40 +0100 Subject: [Koha-devel] check in /check out fails Message-ID: <2db-50f72780-b-278f3000@115563220> Hi, Upon trying to check items out to a patron this message appears: -- Software error: Can't call method "subfield" on an undefined value at /usr/share/koha/lib/C4/Biblio.pm line 3008. The item gets checked out (i.e. it appears in the list of items checked out to the client when you go return to the checkout page). The same happens with check in. The items get checked in, but Koha stops at the error message. What can i do? best, samuel From chris at bigballofwax.co.nz Wed Jan 16 23:22:35 2013 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Thu, 17 Jan 2013 11:22:35 +1300 Subject: [Koha-devel] check in /check out fails In-Reply-To: <2db-50f72780-b-278f3000@115563220> References: <2db-50f72780-b-278f3000@115563220> Message-ID: On 17 January 2013 11:20, Samuel Desseaux wrote: > Hi, > > > Upon trying to check items out to a patron this message appears: > > -- > Software error: > > Can't call method "subfield" on an undefined value at /usr/share/koha/lib/C4/Biblio.pm line 3008. > > > The item gets checked out (i.e. it appears in the list of items checked out to the client when you go return to the checkout page). The same happens with check in. The items get checked in, but Koha stops at the error message. > > What can i do? Is it all items, or just a specific one? Most likely it is a corrupted (or a few corrupted records) Chris > > best, > > samuel > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ From vanoudt at gmail.com Thu Jan 17 09:06:49 2013 From: vanoudt at gmail.com (Nicholas van Rheede van Oudtshoorn) Date: Thu, 17 Jan 2013 16:06:49 +0800 Subject: [Koha-devel] Fedora packages // including PLACK support Message-ID: Hello all! For those that are interested, I've made a repository (the RPM version of a PPA :-) ) to install all of the requirements for koha 3.10 - including those needed to get plack up and running. The repo can be added by running: sudo wget " http://download.opensuse.org/repositories/home:/vanoudt/Fedora_17/home:vanoudt.repo" -O /etc/yum.repos.d/koha.repo A Fedora 18 repo should also be available soon. (I'm running f18, the repo just isn't live yet). Also attached are some systemd service files. Simply copy them into /lib/sytemd/system, copy koha.env into /etc/koha and then enable them using systemctl enable kohazebra.service systemctl enable kohaopac.service systemctl enable kohaopac.service As for plack - WOW! This stuff is amazing. I've made some modifications to the psgi files so that they run using a normal installation from source, and also so that they redirect from an empty URL to the main opac/intranet page. I've attached the psgi files here (install them in /usr/share/koha/psgi ) if anyone is interested! A great new release! Hope these ramblings of mine are of some use to someone! Nicholas van Oudtshoorn Perth Bible College library.pbc.wa.edu.au -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: intranet.psgi Type: application/octet-stream Size: 723 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: koha.env Type: application/octet-stream Size: 63 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: kohaintranet.service Type: application/octet-stream Size: 271 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: kohaopac.service Type: application/octet-stream Size: 261 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: kohazebra.service Type: application/octet-stream Size: 223 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: opac.psgi Type: application/octet-stream Size: 938 bytes Desc: not available URL: From samuel.desseaux at ecp.fr Thu Jan 17 10:12:27 2013 From: samuel.desseaux at ecp.fr (Samuel Desseaux) Date: Thu, 17 Jan 2013 10:12:27 +0100 Subject: [Koha-devel] check in /check out fails In-Reply-To: References: <2db-50f72780-b-278f3000@115563220> Message-ID: <50F7C07B.6000109@ecp.fr> Le 16/01/2013 23:22, Chris Cormack a ?crit : > > Is it all items, or just a specific one? Most likely it is a corrupted > (or a few corrupted records) > > Chris > > It is for most of items. I don't really see where is located the problem. I will create a record and his item and test, that could help me. Samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: samuel_desseaux.vcf Type: text/x-vcard Size: 357 bytes Desc: not available URL: From samuel.desseaux at ecp.fr Thu Jan 17 12:27:28 2013 From: samuel.desseaux at ecp.fr (Samuel Desseaux) Date: Thu, 17 Jan 2013 12:27:28 +0100 Subject: [Koha-devel] sql query / number of items Message-ID: <50F7E020.9020406@ecp.fr> Hi, I need to write a sql query to count the number of 995 field in the records which i 've imported. An idea? Best, samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: samuel_desseaux.vcf Type: text/x-vcard Size: 345 bytes Desc: not available URL: From samuel.desseaux at ecp.fr Thu Jan 17 15:51:47 2013 From: samuel.desseaux at ecp.fr (Samuel desseaux) Date: Thu, 17 Jan 2013 15:51:47 +0100 Subject: [Koha-devel] reindexing with zebra Message-ID: <50F81003.3060302@ecp.fr> Hi, While reindexing zebra, i've this message and some warns i don't understand. Zebra configuration information ================================ Zebra biblio directory = /var/lib/koha/zebradb/biblios Zebra authorities directory = /var/lib/koha/zebradb/authorities Koha directory = /usr/share/koha/intranet/cgi-bin BIBLIONUMBER in : 090$9 BIBLIOITEMNUMBER in : 090$a ================================ ==================== exporting authority ==================== 701.................................................................................................... Records exported: 758 ==================== REINDEXING zebra ==================== 15:41:06-17/01 zebraidx(10724) [warn] /etc/koha/zebradb/authorities/etc/dom-config-marc.xml: stylesheet authority-zebra-indexdefs.xsl not found in path /etc/koha/zebradb/authorities/etc:/etc/koha/zebradb/etc:/etc/koha/zebradb/marc_defs/unimarc/authorities:/etc/koha/zebradb/lang_defs/fr:/etc/koha/zebradb/xsl 15:41:06-17/01 zebraidx(10724) [warn] /etc/koha/zebradb/authorities/etc/dom-config-marc.xml: stylesheet authority-zebra-indexdefs.xsl not found in path /etc/koha/zebradb/authorities/etc:/etc/koha/zebradb/etc:/etc/koha/zebradb/marc_defs/unimarc/authorities:/etc/koha/zebradb/lang_defs/fr:/etc/koha/zebradb/xsl ==================== exporting biblio ==================== 41801.................................................................................................... Records exported: 41805 ==================== REINDEXING zebra ==================== 15:49:11-17/01 zebraidx(10729) [warn] Unknown register type: Best, samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: samuel_desseaux.vcf Type: text/x-vcard Size: 350 bytes Desc: not available URL: From magnus at enger.priv.no Thu Jan 17 20:58:19 2013 From: magnus at enger.priv.no (Magnus Enger) Date: Thu, 17 Jan 2013 20:58:19 +0100 Subject: [Koha-devel] XSLT and superfluous "xmlns" attributes Message-ID: Dear Community! I'm having some XSLT trouble... I have some OAI-PMH records available here: http://sksk.bibkat.no/cgi-bin/koha/oai.pl?verb=ListRecords&metadataPrefix=marcxml The National Library of Norway wants to harvest these records, but they have some very specific requirements, namely that the code for the owning library should be in 850 and that 001 should match the record identifier used in the OAI records identifier. To achieve this, I'm taking advantage of the OAI-PMH:ConfFile syspref, to specify an XSLT stylesheet to transform the records on the fly. Here is the relevant part of the ConfFile: format: biblioteksok: metadataPrefix: biblioteksok metadataNamespace: http://www.loc.gov/MARC21/slim http://www.loc.gov/standards/marcxml/schema/MARC21slim schema: http://www.loc.gov/MARC21/slim http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd xsl_file: /home/magnus/koha/biblioteksok.xslt and here is the stylesheet in /home/magnus/koha/biblioteksok.xslt: 001 850 a NO-1120127 And here is the result of applying the stylesheet: http://sksk.bibkat.no/cgi-bin/koha/oai.pl?verb=ListRecords&metadataPrefix=biblioteksok I was quite pleased with the result myself, but now the National library is complaining that the transformed records do not validate against http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd and that the empty "xmlns" attribute should be removed from the following elements: 93 I have no idea how to achieve that. Does anyone else have a clue? Best regards, Magnus Enger libriotech.no From frederic at tamil.fr Fri Jan 18 09:20:52 2013 From: frederic at tamil.fr (=?UTF-8?B?RnLDqWTDqXJpYyBEZW1pYW5z?=) Date: Fri, 18 Jan 2013 09:20:52 +0100 Subject: [Koha-devel] XSLT and superfluous "xmlns" attributes In-Reply-To: References: Message-ID: <50F905E4.3060809@tamil.fr> > and here is the stylesheet in /home/magnus/koha/biblioteksok.xslt: Try this: Suppress: and replace: with: From mjr at phonecoop.coop Fri Jan 18 18:01:59 2013 From: mjr at phonecoop.coop (MJ Ray) Date: Fri, 18 Jan 2013 17:01:59 +0000 Subject: [Koha-devel] sql query / number of items In-Reply-To: <50F7E020.9020406@ecp.fr> Message-ID: Samuel Desseaux > I need to write a sql query to count the number of 995 field in the > records which i 've imported. > > An idea? Firstly, this is a use query, not a development one, so should be sent to koha at lists.katipo.co.nz and not koha-devel. Secondly, it's probably quite similar to http://wiki.koha-community.org/wiki/SQL_Reports_Library#Duplicate_bibs_using_the_001 but using 995 instead of 001 and count(...) somewhere. Hope that helps, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/ From paul.a at aandc.org Fri Jan 18 18:36:19 2013 From: paul.a at aandc.org (Paul) Date: Fri, 18 Jan 2013 12:36:19 -0500 Subject: [Koha-devel] Contents of more_subfields_xml Message-ID: <5.2.1.1.2.20130118111825.10770d20@stormy.ca> I have recently done some "house-keeping" looking for consistency in the MySQL db (5.5.24 in 3.8.5), and while some tidying up has been straight-forward I am having problems with more_subfields_xml in items. Only about 90% of 'items' have any xml attached to them. Within those that do have an xml entry, only the following subfields appear: entries < 1% entries ~ 20% entries ~ 1.5% entries ~ 95% and they are mostly filled with random values from 2xx, 6xx and 9xx, although the 'code="x"' values appear to be valid from the 952$x. code="f" contains values from 952$v; code="i" has some 952$i valid entries but mostly 650$a,x,y,z; code="k" has random authors, titles, etc - and I can't find where we might use 952$k in our frameworks. Can someone please tell me how these blobs are mapped/created and used by koha? Our odd-ball results/entries don't appear to be having much, if any, influence on cataloguing and search functions. Also, if there is any way to "rebuild" more_subfields_xml -- it's way too big a problem to manage manually. Many thanks - Paul P.S. For completeness, after de-duping all the entries obtained from " SELECT more_subfields_xml FROM items; " (249,636 text lines), the only data left (apart from the subfields above) are "empty containers" using: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.loc.gov/MARC21/slim"> xsi:schemaLocation="http://www.loc.gov/MARC21/slim http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd" a From mh_zalabany at hotmail.com Mon Jan 21 08:12:07 2013 From: mh_zalabany at hotmail.com (Mohamed zalabany) Date: Mon, 21 Jan 2013 07:12:07 +0000 Subject: [Koha-devel] (no subject) Message-ID: hi all i want to know if i have libraries consortium and i need every library see her records only from opac or stuff is their any configuration available from administration to do that or the data will be searchable for all branches the second could we change the opac interface for every library in the consortium when the user of this library enter with his user name and password Mohamed El Zalabany Integrated library systems consultant LibroTech for library systems and information technology http://www.librotech.net mh_zalabany at hotmail.com Mobile: 0111291444 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mh_zalabany at hotmail.com Mon Jan 21 08:14:12 2013 From: mh_zalabany at hotmail.com (Mohamed zalabany) Date: Mon, 21 Jan 2013 07:14:12 +0000 Subject: [Koha-devel] management of consortium In-Reply-To: References: Message-ID: hi all i want to know if i have libraries consortium and i need every library see her records only from opac or stuff is their any configuration available from administration to do that or the data will be searchable for all branches the second could we change the opac interface for every library in the consortium when the user of this library enter with his user name and password Mohamed El Zalabany Integrated library systems consultant LibroTech for library systems and information technology http://www.librotech.net mh_zalabany at hotmail.com Mobile: 0111291444 -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus at enger.priv.no Mon Jan 21 10:52:00 2013 From: magnus at enger.priv.no (Magnus Enger) Date: Mon, 21 Jan 2013 10:52:00 +0100 Subject: [Koha-devel] XSLT and superfluous "xmlns" attributes In-Reply-To: <50F905E4.3060809@tamil.fr> References: <50F905E4.3060809@tamil.fr> Message-ID: On 18 January 2013 09:20, Fr?d?ric Demians wrote: >> and here is the stylesheet in /home/magnus/koha/biblioteksok.xslt: > > Try this: > > Suppress: > > > That did not work, when I left these out the old elements were not removed. > and replace: > > > > with: > > > Ah, that helped! What I ended up using was this: https://gist.github.com/1918264#file-biblioteksok-xslt The clue was including an xmlns-definition on the xsl:element: Thanks for your help Fr?d?ric! Best regards, Magnus From chrisc at catalyst.net.nz Mon Jan 21 20:36:24 2013 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Tue, 22 Jan 2013 08:36:24 +1300 Subject: [Koha-devel] Fedora packages // including PLACK support In-Reply-To: References: Message-ID: <20130121193624.GZ31288@rorohiko.wgtn.cat-it.co.nz> * Nicholas van Rheede van Oudtshoorn (vanoudt at gmail.com) wrote: > Hello all! > > For those that are interested, I've made a repository (the RPM version of > a PPA :-) ) to install all of the requirements for koha 3.10 - including > those needed to get plack up and running. > > The repo can be added by running: > > sudo wget > "http://download.opensuse.org/repositories/home:/vanoudt/Fedora_17/home:vanoudt.repo" > -O /etc/yum.repos.d/koha.repo > Hi Nicholas This is fantastic, I hope some RPM users are trying it out :) Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From fridolyn.somers at biblibre.com Tue Jan 22 16:43:37 2013 From: fridolyn.somers at biblibre.com (Fridolyn SOMERS) Date: Tue, 22 Jan 2013 16:43:37 +0100 Subject: [Koha-devel] (no subject) In-Reply-To: References: Message-ID: <50FEB3A9.5090003@biblibre.com> Hie, I think what you want is multiple OPAC interfaces : http://wiki.koha-community.org/wiki/Support_for_multiple_PAC_interfaces_by_URL_RFC Regards, Le 21/01/2013 08:12, Mohamed zalabany a ?crit : > hi all > i want to know if i have libraries consortium and i need every library > see her records only from opac or stuff > is their any configuration available from administration to do that > or the data will be searchable for all branches > the second > could we change the opac interface for every library in the consortium > when the user of this library enter with his user name and password > > > > Mohamed El Zalabany > Integrated library systems consultant > *LibroTech* > *for library systems and information technology > *http://www.librotech.net* > *mh_zalabany at hotmail.com > Mobile: 0111291444 > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ -- Fridolyn SOMERS Biblibre - P?le Support fridolyn.somers at biblibre.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From fridolyn.somers at biblibre.com Tue Jan 22 16:45:50 2013 From: fridolyn.somers at biblibre.com (Fridolyn SOMERS) Date: Tue, 22 Jan 2013 16:45:50 +0100 Subject: [Koha-devel] About installation in OpenSuse 12.x In-Reply-To: References: Message-ID: <50FEB42E.9050806@biblibre.com> Have a look at : http://comments.gmane.org/gmane.education.libraries.koha.devel/9293 Le 16/01/2013 23:17, John Herz a ?crit : > Hello: > I am looking for instalation instruction in OpenSuse 12.x if any have > some experience, in the wiki only show without zebra configuring :( > > thank you > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ -- Fridolyn SOMERS Biblibre - P?le Support fridolyn.somers at biblibre.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From fridolyn.somers at biblibre.com Tue Jan 22 17:03:11 2013 From: fridolyn.somers at biblibre.com (Fridolyn SOMERS) Date: Tue, 22 Jan 2013 17:03:11 +0100 Subject: [Koha-devel] Contents of more_subfields_xml In-Reply-To: <5.2.1.1.2.20130118111825.10770d20@stormy.ca> References: <5.2.1.1.2.20130118111825.10770d20@stormy.ca> Message-ID: <50FEB83F.40505@biblibre.com> Hie, "items.more_subfields_xml" is the column used to store subfields of item field (952 in MARC21) that are NOT linked with a column of items data table (ie 952$a => items.homebranch). Le 18/01/2013 18:36, Paul a ?crit : > I have recently done some "house-keeping" looking for consistency in > the MySQL db (5.5.24 in 3.8.5), and while some tidying up has been > straight-forward I am having problems with more_subfields_xml in items. > > Only about 90% of 'items' have any xml attached to them. Within those > that do have an xml entry, only the following subfields appear: > > entries < 1% > entries ~ 20% > entries ~ 1.5% > entries ~ 95% > > and they are mostly filled with random values from 2xx, 6xx and 9xx, > although the 'code="x"' values appear to be valid from the 952$x. > code="f" contains values from 952$v; code="i" has some 952$i valid > entries but mostly 650$a,x,y,z; code="k" has random authors, titles, > etc - and I can't find where we might use 952$k in our frameworks. > > Can someone please tell me how these blobs are mapped/created and used > by koha? Our odd-ball results/entries don't appear to be having much, > if any, influence on cataloguing and search functions. > > Also, if there is any way to "rebuild" more_subfields_xml -- it's way > too big a problem to manage manually. > > Many thanks - Paul > > P.S. For completeness, after de-duping all the entries obtained from > " SELECT more_subfields_xml FROM items; " (249,636 text lines), the > only data left (apart from the subfields above) are "empty containers" > using: > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns="http://www.loc.gov/MARC21/slim"> > xsi:schemaLocation="http://www.loc.gov/MARC21/slim > http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd" > > > > > a > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ -- Fridolyn SOMERS Biblibre - P?le Support fridolyn.somers at biblibre.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From mjr at phonecoop.coop Tue Jan 22 19:01:11 2013 From: mjr at phonecoop.coop (MJ Ray) Date: Tue, 22 Jan 2013 18:01:11 +0000 Subject: [Koha-devel] Old bugs to check Message-ID: Would you check some of these rather old bugs to suggest what to do, please? Maybe some can be RESOLVED FIXED by now or need a question. Ideally, tell irc.oftc.net #koha know that you're looking at a bug. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5672 Search History Should have RSS Feeds http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2960 Cyrillic Z39-50 servers (bad encoding results) http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5169 name/rename label batches http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2645 Put Total Due at top of Fines page/seperate paid from unpaid http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5472 Build script needs updating for 3.2.1 release http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3200 missing quotes in rebuild_unimarc_100.pl http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5789 Fines don't work when items have null homebranch http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5501 why is there a 'do not notify' option? http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4125 Bulkmarcimport.pl script has changed a lot without beeing documented http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4874 debian/scripts/koha-* should use Koha instance DB credentials http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3343 duplicate subfields in authority http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5024 Debian packages don't include YUI plugins http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4855 Tools/Export does not tell browser file size http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3147 call to ModZebra in DelAuthority fails (fatal error) if record previously deleted but still exists in index http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5340 bulk subscription renewal http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5721 marc import summary should be filtered or customizable http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5270 007 variable control builder/Specific Material Designation http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3111 Opac lists all ITYPES as same, when database lists different. Other OPAC issues. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5538 would be nice to search both collection code and item type -- Email robot driven by MJ Ray (slef), member of www.software.coop, http://koha-community.org supporter, web and library systems developer. Available for hire (including development) at http://www.software.coop/ From paul.a at aandc.org Wed Jan 23 00:42:33 2013 From: paul.a at aandc.org (Paul) Date: Tue, 22 Jan 2013 18:42:33 -0500 Subject: [Koha-devel] Bug 8641 Message-ID: <5.2.1.1.2.20130122173750.11ac1888@stormy.ca> This bug was signed off a few weeks ago, and is designed to produce a "warning" in the "About" page covering staff use of Koha (not sure if this covers all flag settings down from superlibrarian or if it applies to 3.8. as well as 3.10?) logging in as either "root", "admin (mysql) account" or "database administrative user." I seem to remember (but could be wrong) that after a new 3.8 install, Koha created a "new user", number 0, which was problematic and as far as I can tell exhibited the signs that the warning covers (I have tried to read all details in bugs 8641, 8262 and 9008 plus some references to IRC.) Maybe I'm paranoid, but could someone please clarify how far any problems might extend. If someone sets up a *new* Koha superlibrarian account using the same name/password as system (sudo) user and/or with all MySql privileges, permission tables should not interfere with one another, or overlap, even when identical user/pw combinations are used. Surely this would only apply if staff-user is "koha" or whatever other name was explicitly granted MySql privileges during/immediately after Koha installation. Am I mistaken? Thanks and best regards, Paul From jcamins at cpbibliography.com Wed Jan 23 00:48:09 2013 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Tue, 22 Jan 2013 18:48:09 -0500 Subject: [Koha-devel] Bug 8641 In-Reply-To: <5.2.1.1.2.20130122173750.11ac1888@stormy.ca> References: <5.2.1.1.2.20130122173750.11ac1888@stormy.ca> Message-ID: Paul, This bug was signed off a few weeks ago, and is designed to produce a > "warning" in the "About" page covering staff use of Koha (not sure if this > covers all flag settings down from superlibrarian or if it applies to 3.8. > as well as 3.10?) logging in as either "root", "admin (mysql) account" or > "database administrative user." > > I seem to remember (but could be wrong) that after a new 3.8 install, Koha > created a "new user", number 0, which was problematic and as far as I can > tell exhibited the signs that the warning covers (I have tried to read all > details in bugs 8641, 8262 and 9008 plus some references to IRC.) > You are. User "0" is the database administrative user. Do not use it for anything other than initial installation and upgrades. Ever. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins at cpbibliography.com (web) http://www.cpbibliography.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcamins at cpbibliography.com Wed Jan 23 14:29:24 2013 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Wed, 23 Jan 2013 08:29:24 -0500 Subject: [Koha-devel] RM vacation Message-ID: Good morning. I just wanted to let folks know that the RM will be on vacation starting this Friday, January 25, until Monday, February 4. I anticipate no crises in my absence, and will probably check my e-mail, but the amount of time I spend on testing and pushing will be greatly curtailed. Also, I'll be in California, so if I'm around, it will be four hours later than is my wont. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins at cpbibliography.com (web) http://www.cpbibliography.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at AandC.org Wed Jan 23 16:57:04 2013 From: info at AandC.org (Archives and Collections Society) Date: Wed, 23 Jan 2013 10:57:04 -0500 Subject: [Koha-devel] Bug 8641 In-Reply-To: References: <5.2.1.1.2.20130122173750.11ac1888@stormy.ca> <5.2.1.1.2.20130122173750.11ac1888@stormy.ca> Message-ID: <5.2.1.1.2.20130123090356.0532a808@localhost> At 06:48 PM 1/22/2013 -0500, Jared Camins-Esakov wrote: >Paul, >This bug was signed off a few weeks ago, and is designed to produce a >"warning" in the "About" page covering staff use of Koha (not sure if this >covers all flag settings down from superlibrarian or if it applies to 3.8. >as well as 3.10?) logging in as either "root", "admin (mysql) account" or >"database administrative user." >I seem to remember (but could be wrong) that after a new 3.8 install, Koha >created a "new user", number 0, which was problematic and as far as I can >tell exhibited the signs that the warning covers (I have tried to read all >details in bugs 8641, 8262 and 9008 plus some references to IRC.) >You are. User "0" is the database administrative user. Do not use it for >anything other than initial installation and upgrades. Ever. Thanks Jared. I'm glad that my memory didn't fail me :) and that I never use it. But I'm still interested in the "warning" - particularly as you mention that it should be used for upgrades. As far as I can see (using getent passwd | cut -d : -f 1 | xargs groups) there is no problem with *system* security. Also, User "0" does not appear in the MySql 'borrowers' table. So why is it possible to log in with the "warned against" credentials? How should it be used during upgrades? It also is possible to create a superlibrarian with User "koha" credentials; limited testing in my sandbox has not [yet!] shown any side effects, except that User "0" can no longer log in (demonstrated by the fact that "Library" is set.) Best - Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcamins at cpbibliography.com Wed Jan 23 17:58:31 2013 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Wed, 23 Jan 2013 11:58:31 -0500 Subject: [Koha-devel] Bug 8641 In-Reply-To: <5.2.1.1.2.20130123090356.0532a808@localhost> References: <5.2.1.1.2.20130122173750.11ac1888@stormy.ca> <5.2.1.1.2.20130123090356.0532a808@localhost> Message-ID: Paul, As far as I can see (using getent passwd | cut -d : -f 1 | xargs groups) > there is no problem with *system* security. Also, User "0" does not appear > in the MySql 'borrowers' table. So why is it possible to log in with the > "warned against" credentials? How should it be used during upgrades? > Only the MySQL user (= user 0 ="Koha superuser") can run the webinstaller, if you did not run the upgrade script from the command line (packages take care of it for you, which is one of the reasons why we recommend them). You also must use the database user when an empty database is first created because there is no other superlibrarian user which can be used for administration until after you've created one using your database login. It also is possible to create a superlibrarian with User "koha" > credentials; limited testing in my sandbox has not [yet!] shown any side > effects, except that User "0" can no longer log in (demonstrated by the > fact that "Library" is set.) > Right. The problem with doing that is that if you need to access the web installer, or inadvertently delete all your superlibrarians, you can no longer access Koha using the database credentials, and are therefore stuck. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins at cpbibliography.com (web) http://www.cpbibliography.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From z.tajoli at cineca.it Wed Jan 23 18:33:03 2013 From: z.tajoli at cineca.it (Zeno Tajoli) Date: Wed, 23 Jan 2013 18:33:03 +0100 Subject: [Koha-devel] install all locales to install Koha::Contrib::Tamil Message-ID: <51001ECF.4040607@cineca.it> Hi to all, I'm starting to install Koha on a Debina squeeze amd64. I work from the net-CD so a minimal systen. I want to install Koha::Contrib::Tamil to use background indexing. I see that I need to install all locales to install it with CPAN. I think the problem is in the module Locale::TextDomain. In fact is not a problem, it is quite easy to do with 'sudo dpkg-reconfigure locales' [first option of first menu]. I think this is a useful tip for all. I will update http://wiki.koha-community.org/wiki/Background_indexing_with_Zebra Bye Zeno Tajoli -- Dr. Zeno Tajoli Dipartimento Gestione delle Informazioni e della Conoscenza z.tajoli at cineca.it fax +39 02 2135520 CINECA - Sede operativa di Segrate From paul.a at aandc.org Wed Jan 23 18:36:18 2013 From: paul.a at aandc.org (Paul) Date: Wed, 23 Jan 2013 12:36:18 -0500 Subject: [Koha-devel] Bug 8641 Message-ID: <5.2.1.1.2.20130123123559.055691a8@localhost> At 06:48 PM 1/22/2013 -0500, Jared Camins-Esakov wrote: >Paul, >This bug was signed off a few weeks ago, and is designed to produce a >"warning" in the "About" page covering staff use of Koha (not sure if this >covers all flag settings down from superlibrarian or if it applies to 3.8. >as well as 3.10?) logging in as either "root", "admin (mysql) account" or >"database administrative user." >I seem to remember (but could be wrong) that after a new 3.8 install, Koha >created a "new user", number 0, which was problematic and as far as I can >tell exhibited the signs that the warning covers (I have tried to read all >details in bugs 8641, 8262 and 9008 plus some references to IRC.) >You are. User "0" is the database administrative user. Do not use it for >anything other than initial installation and upgrades. Ever. Thanks Jared. I'm glad that my memory didn't fail me :) and that I never use it. But I'm still interested in the "warning" - particularly as you mention that it should be used for upgrades. As far as I can see (using getent passwd | cut -d : -f 1 | xargs groups) there is no problem with *system* security. Also, User "0" does not appear in the MySql 'borrowers' table. So why is it possible to log in with the "warned against" credentials? How should it be used during upgrades? It also is possible to create a superlibrarian with User "koha" credentials; limited testing in my sandbox has not [yet!] shown any side effects, except that User "0" can no longer log in (demonstrated by the fact that "Library" is set.) Best - Paul _______________________________________________ Koha-devel mailing list Koha-devel at 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. and -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Wed Jan 23 18:47:54 2013 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 23 Jan 2013 11:47:54 -0600 Subject: [Koha-devel] install all locales to install Koha::Contrib::Tamil In-Reply-To: <51001ECF.4040607@cineca.it> References: <51001ECF.4040607@cineca.it> Message-ID: The package is included in squeeze-dev repo that eythian maintains i think. If you are using tar or dev installs you cuold give a try to the koha-index-daemon-ctl.sh script like this: # ln -s /usr/share/koha/bin/koha-index-daemon-ctl.sh /etc/init.d/koha-index-daemon # update-rc.d koha-index-daemon defaults # service koha-index-daemon start and let me know how did it work for you. Regards To+ On Wed, Jan 23, 2013 at 11:33 AM, Zeno Tajoli wrote: > Hi to all, > > I'm starting to install Koha on a Debina squeeze amd64. > I work from the net-CD so a minimal systen. > > I want to install Koha::Contrib::Tamil to use background indexing. > > I see that I need to install all locales to install it with CPAN. > I think the problem is in the module Locale::TextDomain. > > In fact is not a problem, it is quite easy to do with > 'sudo dpkg-reconfigure locales' [first option of first menu]. > > I think this is a useful tip for all. > > I will update > http://wiki.koha-community.org/wiki/Background_indexing_with_Zebra > > Bye > Zeno Tajoli > -- > Dr. Zeno Tajoli > Dipartimento Gestione delle Informazioni e della Conoscenza > z.tajoli at cineca.it > fax +39 02 2135520 > CINECA - Sede operativa di Segrate > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin at catalyst.net.nz Wed Jan 23 22:48:59 2013 From: robin at catalyst.net.nz (Robin Sheat) Date: Thu, 24 Jan 2013 10:48:59 +1300 Subject: [Koha-devel] Bug 8641 In-Reply-To: <5.2.1.1.2.20130123090356.0532a808@localhost> References: <5.2.1.1.2.20130122173750.11ac1888@stormy.ca> <5.2.1.1.2.20130122173750.11ac1888@stormy.ca> <5.2.1.1.2.20130123090356.0532a808@localhost> Message-ID: <1358977739.21154.98.camel@zarathud> Archives and Collections Society schreef op wo 23-01-2013 om 10:57 [-0500]: > As far as I can see (using getent passwd | cut -d : -f 1 | xargs > groups) It's worth noting that there is absolutely, completely no relationship between UNIX system users and Koha or MySQL users. Never the twain shall meet. When you log in with your database username and database password (i.e., the same thing you would use if you typed "mysql -u username -ppassword koha") then you are user 0. However, as user 0 doesn't have an entry in the borrowers database, anything that tries to look you up, or otherwise reference your record will get terribly confused. For our client Koha systems, I only ever user that user for doing quick and dirty things, changing some admin settings, looking at the state of something, creating initial borrowers. Anything more complex than that is likely to have conniptions. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From paul.a at aandc.org Wed Jan 23 23:26:15 2013 From: paul.a at aandc.org (Paul) Date: Wed, 23 Jan 2013 17:26:15 -0500 Subject: [Koha-devel] Bug 8641 In-Reply-To: <1358977739.21154.98.camel@zarathud> References: <5.2.1.1.2.20130123090356.0532a808@localhost> <5.2.1.1.2.20130122173750.11ac1888@stormy.ca> <5.2.1.1.2.20130122173750.11ac1888@stormy.ca> <5.2.1.1.2.20130123090356.0532a808@localhost> Message-ID: <5.2.1.1.2.20130123171600.01eaaf18@localhost> At 10:48 AM 1/24/2013 +1300, Robin Sheat wrote: >Archives and Collections Society schreef op wo 23-01-2013 om 10:57 >[-0500]: > > As far as I can see (using getent passwd | cut -d : -f 1 | xargs > > groups) >It's worth noting that there is absolutely, completely no relationship >between UNIX system users and Koha or MySQL users. Never the twain shall >meet. >When you log in with your database username and database password (i.e., >the same thing you would use if you typed >"mysql -u username -ppassword koha") then you are user 0. However, as >user 0 doesn't have an entry in the borrowers database, anything that >tries to look you up, or otherwise reference your record will get >terribly confused. >For our client Koha systems, I only ever user that user for doing quick >and dirty things, changing some admin settings, looking at the state of >something, creating initial borrowers. Anything more complex than that >is likely to have conniptions. Many thanks Robin -- that was what I had assumed, but confirmation is always good to have. In fact, I have only ever used it to create the very first "superlibrarian" [1] on a new install. May I make a suggestion regarding the sign-off to this bug? (It seemed a bit complex vis-a-vis translations, so I don't want to upset any apple carts.) It might be a good idea to add a para to the INSTALL files (general, Debian, Ubuntu, whatever) to alert people before they get the opportunity to click on "About Koha." I've had a quick look at various 3.8 and 3.10 .tar files and don't find anything. [1] Re: 'borrower' permissions. What's the difference between flag "1" (plain superlibrarian) and flag '261887' (super librarian with all boxes checked)? Is it necessary to check the boxes? Again tnx and br, Paul From liz at catalyst.net.nz Wed Jan 23 23:35:13 2013 From: liz at catalyst.net.nz (Liz Rea) Date: Thu, 24 Jan 2013 11:35:13 +1300 Subject: [Koha-devel] Bug 8641 In-Reply-To: <5.2.1.1.2.20130123171600.01eaaf18@localhost> References: <5.2.1.1.2.20130123090356.0532a808@localhost> <5.2.1.1.2.20130122173750.11ac1888@stormy.ca> <5.2.1.1.2.20130122173750.11ac1888@stormy.ca> <5.2.1.1.2.20130123090356.0532a808@localhost> <5.2.1.1.2.20130123171600.01eaaf18@localhost> Message-ID: <510065A1.2040301@catalyst.net.nz> That message shows up on the home page every time you log in with user 0. It's in a giant yellow box. See: http://imgur.com/kG8xunF Hope that helps, Liz Rea On 24/01/13 11:26, Paul wrote: > At 10:48 AM 1/24/2013 +1300, Robin Sheat wrote: >> Archives and Collections Society schreef op wo 23-01-2013 om 10:57 >> [-0500]: >> > As far as I can see (using getent passwd | cut -d : -f 1 | xargs >> > groups) >> It's worth noting that there is absolutely, completely no relationship >> between UNIX system users and Koha or MySQL users. Never the twain shall >> meet. >> When you log in with your database username and database password (i.e., >> the same thing you would use if you typed >> "mysql -u username -ppassword koha") then you are user 0. However, as >> user 0 doesn't have an entry in the borrowers database, anything that >> tries to look you up, or otherwise reference your record will get >> terribly confused. >> For our client Koha systems, I only ever user that user for doing quick >> and dirty things, changing some admin settings, looking at the state of >> something, creating initial borrowers. Anything more complex than that >> is likely to have conniptions. > > Many thanks Robin -- that was what I had assumed, but confirmation is > always good to have. In fact, I have only ever used it to create the > very first "superlibrarian" [1] on a new install. > > May I make a suggestion regarding the sign-off to this bug? (It seemed > a bit complex vis-a-vis translations, so I don't want to upset any > apple carts.) It might be a good idea to add a para to the INSTALL > files (general, Debian, Ubuntu, whatever) to alert people before they > get the opportunity to click on "About Koha." I've had a quick look at > various 3.8 and 3.10 .tar files and don't find anything. > > [1] Re: 'borrower' permissions. What's the difference between flag "1" > (plain superlibrarian) and flag '261887' (super librarian with all > boxes checked)? Is it necessary to check the boxes? > > Again tnx and br, > Paul > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ From liz at catalyst.net.nz Wed Jan 23 23:46:41 2013 From: liz at catalyst.net.nz (Liz Rea) Date: Thu, 24 Jan 2013 11:46:41 +1300 Subject: [Koha-devel] Bug 8641 In-Reply-To: <5.2.1.1.2.20130123171600.01eaaf18@localhost> References: <5.2.1.1.2.20130123090356.0532a808@localhost> <5.2.1.1.2.20130122173750.11ac1888@stormy.ca> <5.2.1.1.2.20130122173750.11ac1888@stormy.ca> <5.2.1.1.2.20130123090356.0532a808@localhost> <5.2.1.1.2.20130123171600.01eaaf18@localhost> Message-ID: <51006851.7020005@catalyst.net.nz> There is also a bug, 9439, that is pending sign off that would rectify the exact situation you are describing. Essentially, there is no difference between them, and the patch for 9439 just enforces that. Liz Rea On 24/01/13 11:26, Paul wrote: > At 10:48 AM 1/24/2013 +1300, Robin Sheat wrote: >> Archives and Collections Society schreef op wo 23-01-2013 om 10:57 >> [-0500]: >> > As far as I can see (using getent passwd | cut -d : -f 1 | xargs >> > groups) >> It's worth noting that there is absolutely, completely no relationship >> between UNIX system users and Koha or MySQL users. Never the twain shall >> meet. >> When you log in with your database username and database password (i.e., >> the same thing you would use if you typed >> "mysql -u username -ppassword koha") then you are user 0. However, as >> user 0 doesn't have an entry in the borrowers database, anything that >> tries to look you up, or otherwise reference your record will get >> terribly confused. >> For our client Koha systems, I only ever user that user for doing quick >> and dirty things, changing some admin settings, looking at the state of >> something, creating initial borrowers. Anything more complex than that >> is likely to have conniptions. > > Many thanks Robin -- that was what I had assumed, but confirmation is > always good to have. In fact, I have only ever used it to create the > very first "superlibrarian" [1] on a new install. > > May I make a suggestion regarding the sign-off to this bug? (It seemed > a bit complex vis-a-vis translations, so I don't want to upset any > apple carts.) It might be a good idea to add a para to the INSTALL > files (general, Debian, Ubuntu, whatever) to alert people before they > get the opportunity to click on "About Koha." I've had a quick look at > various 3.8 and 3.10 .tar files and don't find anything. > > [1] Re: 'borrower' permissions. What's the difference between flag "1" > (plain superlibrarian) and flag '261887' (super librarian with all > boxes checked)? Is it necessary to check the boxes? > > Again tnx and br, > Paul > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ From z.tajoli at cineca.it Thu Jan 24 13:18:21 2013 From: z.tajoli at cineca.it (Zeno Tajoli) Date: Thu, 24 Jan 2013 13:18:21 +0100 Subject: [Koha-devel] install all locales to install Koha::Contrib::Tamil In-Reply-To: References: <51001ECF.4040607@cineca.it> Message-ID: <5101268D.9010809@cineca.it> Hi Tomas, Il 23/01/2013 18:47, Tomas Cohen Arazi ha scritto: > The package is included in squeeze-dev repo that eythian maintains i > think. If you are using tar or dev installs you cuold give a try to the > koha-index-daemon-ctl.sh script like this: > > # ln -s /usr/share/koha/bin/koha-index-daemon-ctl.sh > /etc/init.d/koha-index-daemon > # update-rc.d koha-index-daemon defaults > # service koha-index-daemon start > > and let me know how did it work for you. I'm try to use it. In general I prefer to use sudo /etc/init.d/koha-index-daemon start. Normaly I dont' use the sysvconfig package. Well in the file koha-index-daemon-ctl.sh I see those lines: USER=__KOHA_USER__ GROUP=__KOHA_GROUP__ DBNAME=__DB_NAME__ I use the 3.10.2, this script is not present so I download it from git archive. The values USER and GROUP are quite easy but could you explain main the meaning of DBNAME ? I think it is the name of MySQL db, but I'm not sure. An other question: Do you think is correct to use this script and Koha::Contrib::Tamil to setup different index daemons on the same HW ? For every Koha installation a different linux user, a different mysql db and user, differnt dirs, different envs an different index daemon in /etc/init.d/. But one daemon work only on one koha installation. Do you think it work ? Bye Zeno Tajoli -- Dr. Zeno Tajoli Dipartimento Gestione delle Informazioni e della Conoscenza z.tajoli at cineca.it fax +39 02 2135520 CINECA - Sede operativa di Segrate From joseanjos at gmail.com Thu Jan 24 13:32:33 2013 From: joseanjos at gmail.com (anjoze) Date: Thu, 24 Jan 2013 04:32:33 -0800 (PST) Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: <5.2.1.1.2.20120821201313.01af8798@localhost> References: <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120821172557.0269bea8@localhost> <5.2.1.1.2.20120821190421.01b97d48@localhost> <5.2.1.1.2.20120821201313.01af8798@localhost> Message-ID: <1359030753509-5740073.post@n5.nabble.com> Paul A wrote > At 08:06 AM 8/22/2012 +0800, [someone, because this is not personal] > wrote: > ... > > Errors were encountered while processing: > /var/cache/apt/archives/libxml2-dev_2.7.8.dfsg-5.1ubuntu4.1_i386.deb > E: Sub-process /usr/bin/dpkg returned an error code (1) > Some errors occurred while unpacking. Packages that were installed > will be configured. This may result in duplicate errors > or errors caused by missing dependencies. This is OK, only the errors > above this message are important. Please fix them and run [I]nstall again > Press enter to continue. > Errors were encountered while processing: * > libxslt1-dev:i386 * I had the same problem and the solution was: *sudo apt-get remove libxslt1-dev:i386* Than it worked ok with the dselect ----- Koha version: 3.08.04 - - Jos? Anjos -- View this message in context: http://koha.1045719.n5.nabble.com/koha-zebra-daemon-not-starting-tp5723716p5740073.html Sent from the Koha-devel mailing list archive at Nabble.com. From tomascohen at gmail.com Thu Jan 24 13:49:40 2013 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Thu, 24 Jan 2013 06:49:40 -0600 Subject: [Koha-devel] install all locales to install Koha::Contrib::Tamil In-Reply-To: <5101268D.9010809@cineca.it> References: <51001ECF.4040607@cineca.it> <5101268D.9010809@cineca.it> Message-ID: On Thu, Jan 24, 2013 at 6:18 AM, Zeno Tajoli wrote: > > Hi Tomas, > > Il 23/01/2013 18:47, Tomas Cohen Arazi ha scritto: > > The package is included in squeeze-dev repo that eythian maintains i > > think. If you are using tar or dev installs you cuold give a try to the > > koha-index-daemon-ctl.sh script like this: > > > > # ln -s /usr/share/koha/bin/koha-index-daemon-ctl.sh > > /etc/init.d/koha-index-daemon > > # update-rc.d koha-index-daemon defaults > > # service koha-index-daemon start > > > > and let me know how did it work for you. > > I'm try to use it. > In general I prefer to use sudo /etc/init.d/koha-index-daemon start. > Normaly I dont' use the sysvconfig package. > > Well in the file koha-index-daemon-ctl.sh I see those lines: > > USER=__KOHA_USER__ > GROUP=__KOHA_GROUP__ > DBNAME=__DB_NAME__ > > I use the 3.10.2, this script is not present so I download it from git > archive. > The values USER and GROUP are quite easy but could you explain main the > meaning of DBNAME ? > I think it is the name of MySQL db, but I'm not sure. If you installed from master, DBNAME should be the database name for that Koha instance. In fact it is intended to clearly separate one instance's script from the other (script name, working dir, etc). > An other question: > Do you think is correct to use this script and Koha::Contrib::Tamil > to setup different index daemons on the same HW ? This script is just a valid (LSB) init script for Koha::Contrib::Tamil's daemon you can use for each instance you install via the usual procedure. Once it was pushed into master i was waiting for somefeedback prior to documenting it more publicly. My goal was to simplify the darkest bit of a Koha setup for the general public. > For every Koha installation a different linux user, a different mysql db > and user, differnt dirs, different envs an different index daemon in > /etc/init.d/. > But one daemon work only on one koha installation. > Do you think it work ? We have used (another less polished version of) this init script in our 38+ instances setup for almost two years. First, with the daemon I wrote a while ago, and then moved to Tamil's as it was favoured by the dev community. Regards To+ From fridolyn.somers at biblibre.com Thu Jan 24 16:30:08 2013 From: fridolyn.somers at biblibre.com (Fridolyn SOMERS) Date: Thu, 24 Jan 2013 16:30:08 +0100 Subject: [Koha-devel] about records in koha pro In-Reply-To: <50F6A8D7.7090000@ecp.fr> References: <50F6A8D7.7090000@ecp.fr> Message-ID: <51015380.3060004@biblibre.com> Hie, this exists in actual Koha version, it is the "opac browse results" feature. See http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6483 Le 16/01/2013 14:19, Samuel Desseaux a ?crit : > Hi, > > I've a question of my colleagues. > > In the opac, when i'm looking for something, i've the results and when > i choose one of the results, i can add a link to come back to the > results and another link to the search > > example: i make a research and it gives the results > http://koha.ecp.fr:8080/cgi-bin/koha/catalogue/search.pl?q=eau > > I choose one of the result and there, i 'd be able to see the next > record which is in the list of results. Is it possible? I hope that > you will understand my request. > > Best regards, > > samuel > > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ -- Fridolyn SOMERS Biblibre - P?le Support fridolyn.somers at biblibre.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From mathieu.saby at univ-rennes2.fr Sun Jan 27 23:54:14 2013 From: mathieu.saby at univ-rennes2.fr (Mathieu Saby) Date: Sun, 27 Jan 2013 23:54:14 +0100 Subject: [Koha-devel] Definition of Zebra indexes without bib1 att Message-ID: <5105B016.2080208@univ-rennes2.fr> Hello I thought it was mandatory for creating an index in Zebra to edit 3 files (record.abs, ccl.properties, bib1.att). cf http://wiki.koha-community.org/wiki/Understanding_Zebra_indexing But I was surprised to find some indexes that are actually usable (in search menu) without any definition in bib1.att. They are all related to UNIMARC coded information (fields 100/105/115/116): video-mt 1=Video-mt Video-mt video-mt Graphics-type 1=Graphic-type Graphics-support 1=Graphic-support Type-Of-Serial 1=Type-Of-Serial Frequency-code 1=Frequency-code Regularity-code 1=Regularity-code Material-type 1=Material-type Literature-Code 1=Literature-Code Biography-code 1=Biography-code Illustration-code 1=Illustration-code Could somebody gives me some light? Does that mean defining a numeric attribute in bib1.att is a good practice, but not technically mandatory? Should this syntax be corrected? Regards, M. Saby -- Mathieu Saby Service d'Informatique Documentaire Service Commun de Documentation Universit? Rennes 2 T?l?phone : 02 99 14 12 65 Courriel : mathieu.saby at univ-rennes2.fr From sandeep.bhavsar at gmail.com Tue Jan 29 08:20:53 2013 From: sandeep.bhavsar at gmail.com (SANDEEP BHAVSAR) Date: Tue, 29 Jan 2013 12:50:53 +0530 Subject: [Koha-devel] Koha Upgrade- git Message-ID: Dear All I have upgraded the Koha through git on 23/01/2013. and today I have changed the IP address ( Koha.httpd.conf) but after that when I searched in OPAC, I am getting only the No. of books available for specific term is (257) and in records the message is " Availability: No copies available " Please guide. -- Thanks and Regards Sandeep Bhavsar Librarian Dr.V.N.Bedekar Institute of Management Studies Thane(W) 400601 MUMBAI. INDIA @@@@@@@@@@@@@@@@@@@@@@@@@@ email : sandeep.bhavsar at gmail.com Mob : 9987049099 elibrary :http://www.vpmthane.org/im/elib/main.htm @@@@@@@@@@@@@@@@@@@@@@@@@@ -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Wed Jan 30 10:42:03 2013 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 30 Jan 2013 10:42:03 +0100 Subject: [Koha-devel] Reminder = Hackfest in Marseille in less than 2 months ! Message-ID: <5108EAEB.3060502@biblibre.com> Hello koha hackers, A quick reminder to everyone = BibLibre organize, for the 3rd year, a hackfest in Marseille, in March, 18th to 22nd. There are already 30 ppl registered (18 BibLibre and 12 externals). It's a great time to hack and have fun on Koha. There will be people from Norway, Germany, USA. People from Italy, Spain, UK, Switzerland, Netherlands, Poland, Greece, and all other countries around the world, you're welcomed !!! Just drop me a mail if you want more informations, or plan to come ! -- Paul POULAIN - BibLibre http://www.biblibre.com Free & Open Source Softwares for libraries Koha, Drupal, Piwik, Jasper From indradg at gmail.com Wed Jan 30 23:21:26 2013 From: indradg at gmail.com (Indranil Das Gupta) Date: Thu, 31 Jan 2013 03:51:26 +0530 Subject: [Koha-devel] A browser-based (javascript) non-Latin IME for Koha Message-ID: Hi all, I have a requirement to support about cataloging and searching on about 6 Indian languages on Koha v 3.10. The GoogleIndicTransliteration syspref seems to have been discarded even though doc-head-close.inc has its reference. While it is always possible to use a OS-based system input method, my client has a preference for a browser-based one, I have taken Wikimedia foundation's jquery IME (https://github.com/wikimedia/jquery.ime/#readme) - a dual-licensed javascript library - GPLv2+ and MIT licensed. the IME is a port of the Narayam IME used for non-Latin input on Wikipedia. I've done the following: 1. Installed the latest jquery.ime git master into 3.10 code tree. 2. modified lib/C4/Templates.pm to add an additional 'jqueryimepath' parameter/variable 3. added the necessary lines to includes/doc-head-close.inc 4. changed the path to the IME 'rules' files to point to koha source tree location, in order to work correctly after being served by mod_rewrite What I'm about to do: 1. Add a new syspref to toggle use of the JQuery IME, so that users have an option to enable / disable it. I would like to contribute this as a feature to the upcoming Koha release(s). Question: How do I do this? Cluesticks/bats anyone? ;-) cheers, -indra -- Indranil Das Gupta Phone : +91-98300-20971 Blog : http://indradg.randomink.org/blog IRC : indradg on irc://irc.freenode.net Twitter : indradg -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=- Please exchange editable Office documents only in ODF Format. No other format is acceptable. Support Open Standards. For a free editor supporting ODF, please visit LibreOffice - http://www.documentfoundation.org From indradg at gmail.com Wed Jan 30 23:56:05 2013 From: indradg at gmail.com (Indranil Das Gupta) Date: Thu, 31 Jan 2013 04:26:05 +0530 Subject: [Koha-devel] A browser-based (javascript) non-Latin IME for Koha In-Reply-To: References: Message-ID: Hi, On Thu, Jan 31, 2013 at 3:51 AM, Indranil Das Gupta wrote: > Hi all, > I would like to contribute this as a feature to the upcoming Koha release(s). > > Question: How do I do this? Cluesticks/bats anyone? ;-) As a start, I've filed the following bug - http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9515 cheers, -indra -- Indranil Das Gupta Phone : +91-98300-20971 Blog : http://indradg.randomink.org/blog IRC : indradg on irc://irc.freenode.net Twitter : indradg -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=- Please exchange editable Office documents only in ODF Format. No other format is acceptable. Support Open Standards. For a free editor supporting ODF, please visit LibreOffice - http://www.documentfoundation.org From gmc at esilibrary.com Thu Jan 31 00:16:32 2013 From: gmc at esilibrary.com (Galen Charlton) Date: Wed, 30 Jan 2013 15:16:32 -0800 Subject: [Koha-devel] A browser-based (javascript) non-Latin IME for Koha In-Reply-To: References: Message-ID: Hi, On Wed, Jan 30, 2013 at 2:56 PM, Indranil Das Gupta wrote: > On Thu, Jan 31, 2013 at 3:51 AM, Indranil Das Gupta wrote: >> Hi all, > >> I would like to contribute this as a feature to the upcoming Koha release(s). >> >> Question: How do I do this? Cluesticks/bats anyone? ;-) > > As a start, I've filed the following bug - > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9515 Good first step! Since you've already got this working in your local installation of Koha, preparing your work for submission will mostly be a matter of creating a Git clone of the Koha source repository, running through the steps to add the IME in your clone, then creating a patch and submitting it. I recommend that you read through the following wiki page first, which goes over the mechanics using Git and preparing a patch: http://wiki.koha-community.org/wiki/Version_Control_Using_Git Once you have the patch in your local repository, you should also read: http://wiki.koha-community.org/wiki/Git_bz_configuration As you work your way through this, I encourage you to post more questions on koha-devel or ask them in #koha. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org From danielg.koha at gmail.com Thu Jan 31 23:04:09 2013 From: danielg.koha at gmail.com (Daniel Grobani) Date: Thu, 31 Jan 2013 14:04:09 -0800 Subject: [Koha-devel] January 2013 Koha Community Newsletter has been published Message-ID: Hi, The January 2013 edition of the Koha Community Newsletter has been posted to http://koha-community.org/koha-community-newsletter-january-2013/. Cheers, Daniel Grobani Koha Community Newsletter Editor -------------- next part -------------- An HTML attachment was scrubbed... URL: