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

Old bugs to check
by MJ Ray 07 May '13

07 May '13

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. Please leave your reply on the bug web page - I might not see replies to this mail. Ideally, tell irc.oftc.net #koha know that you're looking at a bug. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5365 cannot reopen a basket http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6422 help files for the OPAC http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5992 Biblibre various improvements for 3.4 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5383 Test of Process to Submit a Feature Request http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5627 lock symbol even on not locked fields http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5276 subscription info shouldn't be required http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5884 ability to print on label sheet with diff sized labels http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4076 Clearing payment history http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2927 Saving on enter http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5590 error message on holds not consistent http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5541 links show title twice if 856$y and 856$3 populated http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2426 Management Permissions Deprecated http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5196 006 subfields 01-17 should be populated depending on the 00 value http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3153 'maxoutstanding' syspref does not disallow placing holds on staff side http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3460 Hold options inconsistent for "Damaged" items http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5592 circ rule cloning can be dangerous http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5823 Repeated check in of on-hold item fails to show hold information http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6122 Catalogue reports exclude biblio without item http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5334 add explicit foreign key constraints -- 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/

1 0

Please select 5 popular languages for inclusion in Koha Live DVD
by Vimal Kumar 07 May '13

07 May '13

Dear Friends, I got suggestions to add few additional languages rather than English in Koha Live DVD. Please select popular 5 languages for this purpose. The five languages translation must be finished. I request Translation manager to select 5 languages to include in the Koha Live DVD. Vimal Kumar V. Koha Live DVD Manager (ver. 3.12.x) www.vimalkumar.info

2 1

Re: [Koha-devel] Major surprise - "automatic" upgrade
by Paul 07 May '13

07 May '13

Good morning all, Many thanks. I've got a major exhibition opening Saturday (and our annual dinner) but will get back to this early next week. Not sure what you mean by "screencast" so will assume that the complete CLI readout will be OK ... Best - Paul At 06:41 PM 4/30/2013 -0400, Ian Walls wrote: >Paul, > > >You mentioned earlier in this thread that you could reproduce this issue >now that you've restored.Â Would it be possible for you to create a >screencast of what steps you're taking and what your output is for each of >those steps?Â When you're performing the commandline operations, what >directory are you in?Â What are you KOHA_CONF and PERL5LIB >variables?Â Is your KOHA_CONF appropriate for the paths of your current >version of the software, and does it point to the right iteration of your >database? > >Chris, Jared and Mason are right; the code simply cannot upgrade the >database without running >installer/data/mysql/<http://updatedatabase.pl>updatedatabase.pl, which is >not invoked in >misc/cronjobs/<http://cleanup_database.pl>cleanup_database.pl.Â The >prototypical way to do this update is through the web installer; if the >system detects that your codebase version is greater than your database >version, it will take you to the update page in the staff client.Â You >then login with the username/password that MySQL has for your koha >database, and the updates are performed.Â It's also possible to run this >manually on the commandline; is there any chance you have any configured >triggers in place to invoke this command? > >This is definitely a confusing situation, and I'm sorry it's cause you >alarm.Â Hopefully with more information we can get to the bottom of >exactly how it's happening, understand it, and prevent it from happening >to you (and anyone else) again. > >Cheers, > > >-Ian > > >On Tue, Apr 30, 2013 at 6:20 PM, Chris Cormack ><<mailto:chris@bigballofwax.co.nz>chris(a)bigballofwax.co.nz> wrote: >There is no way, no way at all that running ><http://cleanup_database.pl>cleanup_database.pl did >the upgrade. It didn't. >The only way you would get the webpage telling you your db needed >updating is because the code is different to the db. >This means your Koha was pointing to the 3.8.10 code. Not the 3.8.5 one. > >This can only happen if you untarred the code over top of your 3.8.5, >or ran make upgrade, or edited your koha-conf.xml and apache config to >point at the new code. > >None of this was caused by you running ><http://cleanup_database.pl>cleanup_database.pl, That is a >red herring. > >So by you logging into the web installer and telling it to update your >db, you updated your db, you untarring the 3.8.10 and somehow >switching your koha site to use that (one of the ways above) you were >running 3.8.10 which triggered the screen telling you you needed to >upgrade your db to match. > >None of this was automatic and I repeat none of this was caused by ><http://cleanup_database.pl>cleanup_database.pl. > >This will also be my last message on this subject, but I can not leave >the thread with the assertion that somehow running ><http://cleanup_database.pl>cleanup_database.pl >downloaded a tarball, untarred it, ran make upgrade, and then logged >into your koha installer page with the db user and clicked update >database. It didn't. > >If you really didn't do it yourself, then yes, the only other >conclusion is you were/are hacked by someone who likes to upgrade Koha > >Chris > >On 1 May 2013 10:10, Paul <<mailto:paul.a@aandc.org>paul.a(a)aandc.org> wrote: > > At 06:44 AM 5/1/2013 +1200, Mason James wrote: > > [snip] > > > >> lol, no Paul - i do not 'misunderstand' anything here > > > > > > I'm not laughing, I'm "a little worried." > > > > > >> hmmm, your 'automatic upgrade' was caused by... > >> > >> Â - you manually pointing your 3.8.5 Koha to a 3.8.10 codebase, (then > >> forgetting you did that) > > > > > > No. (and despite my advancing years, not only is my memory way above > > average, but I keep notes of everything I do. On this particular box, I did > > a wget for the tarball to /home/paul/, tar xvfz'ed to /home/paul/, and > cp'ed > > the .gz to / with the unfulfilled intention of upgrading, all on 23 Feb > this > > year.) > > > > > >> Â - you manually logging-in as the Koha database user at the > >> install/upgrade page > > > > > > No. I was logged in as user=koha to run > './<http://cleanup_database.pl>cleanup_database.pl --zebraqueue > > -v', *not* at any "install" page. > > > > > >> Â - you manually clicking 'upgrade' > > > > > > No. Or rather, upgrade what? > > > > For an upgrade 3.8.5 ==> 3.8.10, categorically "No." > > > > After running './<http://cleanup_database.pl>cleanup_database.pl > --zebraqueue -v', neither the OPAC nor > > the staff/8080 interface was available. My only way forward was a > > "staff/8080" login as user=koha and agree to "Web installer âº Step 3: > update > > your database" -- note *database*, nothing about version. > > > >> Did i miss anything?? > > > > > > Yes. Using '-v' with <http://cleanup_database.pl>cleanup_database.pl > was not verbose. It was totally > > silent on version upgrade, only advised: > > > > koha@hardy:/usr/share/koha/bin/cronjobs$ > ./<http://cleanup_database.pl>cleanup_database.pl --zebraqueue > > -v > > Zebraqueue purge triggered for 30 days. > > > > 131575 records were deleted. > > Done with zebraqueue purge. > > > > Yes. I was operating as user=koha to run > <http://cleanup_database.pl>cleanup_database.pl. The fact is > > that the Koha version went from 3.8.5 to 3.8.10 without my permission. > > > > Yes. user=koha has the permissions to upgrade versions, but why does > > <http://cleanup_database.pl>cleanup_database.pl (specifically the > '--zebraqueue -v' option) upgrade > > versions at the same time? > > > > I truly appreciate your reply. But your suggestion that I "manually" > did one > > of the three points you raised is untrue. Did the version upgrade happen? > > Yes. Did user=koka have the rights? Yes. Was I given any warning? No. Is > > there any reason why <http://cleanup_database.pl>cleanup_database.pl > should have anything to do with > > upgrading versions? That is my question. It did it. It's reproducible on my > > sandbox (and I'd be interested if others can confirm/deny.) > > > > Best -- Paul > > > > > > --- > > Maritime heritage and history, preservation and conservation, > > research and education through the written word and the arts. > > <<http://NavalMarineArchive.com>http://NavalMarineArchive.com> and > <<http://UltraMarine.ca>http://UltraMarine.ca> > > > > _______________________________________________ > > Koha-devel mailing list > > > <mailto:Koha-devel@lists.koha-community.org>Koha-devel(a)lists.koha-community.org > > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > > website : <http://www.koha-community.org/>http://www.koha-community.org/ > > git : <http://git.koha-community.org/>http://git.koha-community.org/ > > bugs : <http://bugs.koha-community.org/>http://bugs.koha-community.org/ >_______________________________________________ >Koha-devel mailing list ><mailto:Koha-devel@lists.koha-community.org>Koha-devel(a)lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : <http://www.koha-community.org/>http://www.koha-community.org/ >git : <http://git.koha-community.org/>http://git.koha-community.org/ >bugs : <http://bugs.koha-community.org/>http://bugs.koha-community.org/ > --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

4 5

Translation Manager for 3.14
by Bernardo Gonzalez Kriegel 07 May '13

07 May '13

Hi all, I'm so sorry to have missed the meeting, my apologies. Anyway, I'm glad to have been elected, and expect to a do good job at that post. My sincere thanks for the opportunity, Bernardo -- Bernardo Gonzalez Kriegel bgkriegel(a)gmail.com

2 1

Debian Wheezy (7.0) is out !
by Paul Poulain 07 May '13

07 May '13

Hi koha-devel, You may have seen that Debian Wheezy is out : http://www.debian.org/News/2013/20130504 Did someone already have upgraded from Squeeze ? What's our next steps ? -- Paul POULAIN - BibLibre http://www.biblibre.com Free & Open Source Softwares for libraries Koha, Drupal, Piwik, Jasper

4 4

Re: [Koha-devel] Major surprise - "automatic" upgrade
by Archives and Collections Society 07 May '13

07 May '13

At 06:41 PM 4/30/2013 -0400, Ian Walls wrote: [snip] >This is definitely a confusing situation, and I'm sorry it's cause you >alarm.Â Hopefully with more information we can get to the bottom of >exactly how it's happening, understand it, and prevent it from happening >to you (and anyone else) again. Thanks to all for your patience, summary of my "reproducible upgrade" is that under some | [perhaps] exceptional conditions 'cleanup_database.pl' does upgrade the Koha version. Under what might be called "normal" conditions, absolutely everything is as expected with no problems. You'll see from the notes below, that having a *koha owned* koha-3.08.10 at / prompts a version upgrade [the *Important Note* below.] There is no "verbosity" using -v with './cleanup_database.pl' Best - Paul Update 6 May: Logged in as user=koha, no tarred|untarred Koha installation files on this box koha@hardy:/$ cat /usr/share/koha/misc/koha-install-log | grep KOHA_INSTALLED_VERSION KOHA_INSTALLED_VERSION=3.08.05.000 koha@hardy:/usr/share/koha/bin/cronjobs$ ./cleanup_database.pl --zebraqueue 1 -v Zebraqueue purge triggered for 1 days. 19847 records were deleted. Done with zebraqueue purge. cat /usr/share/koha/misc/koha-install-log | grep KOHA_INSTALLED_VERSION KOHA_INSTALLED_VERSION=3.08.05.000 So far, so good; OPAC and staff-admin both functional. To reproduce upgrade, restore db; sftp [...] koha-3.08.05.tar.gz and koha-3.08.10.tar.gz /home/paul; "untar" koha-3.08.10.tar.gz in /home/paul/; cp koha-3.08.10.tar.gz to / koha@hardy:/$ ls -l /home/paul /.../ -rwxrw-r-- 1 paul paul 48446365 Sep 22 2012 koha-3.08.05.tar.gz -rwxrw-r-- 1 paul paul 50084604 Mar 2 19:34 koha-3.08.10.tar.gz drwxrwxr-x 42 paul paul 4096 Feb 23 05:09 koha-3.08.10 koha@hardy:/$ ls -l / / ... / -rw-r--r-- 1 koha koha 50084604 May 6 18:26 koha-3.08.10.tar.gz drwxrwxr-x 42 koha koha 4096 Feb 23 05:09 koha-3.08.10 [Important Note: if chown is either "me" or root, the following version upgrade does not happen.] koha@hardy:/usr/share/koha/bin/cronjobs$ ./cleanup_database.pl --zebraqueue 1 -v Zebraqueue purge triggered for 1 days. 19847 records were deleted. Done with zebraqueue purge. cat /usr/share/koha/misc/koha-install-log | grep KOHA_INSTALLED_VERSION KOHA_INSTALLED_VERSION=3.08.10.000 ... and OPAC announces under "maintenance". Trying to staff-admin: Web installer Step 3 We are upgrading from Koha 3.08.05.000 to 3.08.10.000, you must update your database Web installer Step 3 Updating database structure Update report : Upgrade to 3.08.06.000 (3.8.6 release) done Upgrade to 3.08.07.000 (3.8.7 release) done Upgrade to 3.08.08.000 (3.8.8 release) done Upgrade to 3.08.09.000 (3.8.9 release) done Upgrade to 3.08.10.000 (3.8.9 release) done Everything went OK, update done. Continue to log in to Koha

1 0

Need wallpaper volunteers
by Vimal Kumar V. 05 May '13

05 May '13

Dear Friends, Please put forward some suggestions for Koha Live DVD wallpaper. And need someones help to create a beautiful wallpaper for Koha Live DVD. Regards, -- Vimal Kumar V. Mahatma Gandhi University Library Kottayam, Kerala- 686 560 Web: http://www.vimalkumar.info Blog: http://linuxhalwa.blogspot.com http://kohageek.blogspot.in --------------------------------------------------------------------------- "I forget what I was taught. I only remember what I have learnt" -Patrick White

1 1

Error while running fines cron
by Scott Kushner 04 May '13

04 May '13

Running Koha 3.10.05 Community.... Not sure why. root@mtplkohacomm:/home/koha/kohaclone/misc/cronjobs# perl fines.pl Use of uninitialized value in string eq at /home/koha/kohaclone/C4/Context.pm line 1030. Use of uninitialized value in string eq at /home/koha/kohaclone/C4/Context.pm line 1030. Use of uninitialized value in string eq at /home/koha/kohaclone/C4/Context.pm line 1030. Thanks, Scott Kushner Middletown Library

2 1

biblio and biblioitems
by Mathieu Saby 03 May '13

03 May '13

Hello Could you tell me if there is some reason for keeping bibliographic information in 2 tables (biblio / biblioitems). I don't see any case where 1 biblionumber could match more than 1 biblioitemnumber. Maybe it is an heritage of the first versions of Koha? 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(a)univ-rennes2.fr

6 9

biblio records causing "previous transaction didn't reach commit" in zebra
by Gaetan Boisson 03 May '13

03 May '13

Hello all, we are migrating some csv data to marc21 and a small percentage of the resulting records are giving this error in zebra when we try indexing them. I have been looking at them toroughly and am failing to see what could possibly cause this, especially when i compare them to records that did work. I'm enclosing a couple here in case you want to have a look and might have an idea... It is for a Kurdish university so you'll find a lot of unusual characters in there, but we have these in records that work out too. The U+200 characters are here to set the context properly for the script direction. They are superfluous quite often, but they also don't hurt and are present in data that gets indexed properly. Thanks for your input ! -- Gaetan Boisson Chef de projet bibliothécaire BibLibre 06 52 42 51 29 108 avenue Breteuil 13006 Marseille gaetan.boisson(a)biblibre.com

1 0