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

updatedatabase.pl
by Marcel de Rooy 09 Sep '16

09 Sep '16

Please correct one of the latest db revs. 16.06.00.016 and 16.06.00.017 are now the same and should not be. Thanks, Marcel

2 1

SPAM in bugzilla: what do we do ?
by Tajoli Zeno 08 Sep '16

08 Sep '16

Hi to all, Watching new bug in bugzilla I see around one SPAM 'bug' every 2 day. What do we want to do with those 'bugs' ? Bye Zeno Tajoli -- Zeno Tajoli /SVILUPPO PRODOTTI CINECA/ - Automazione Biblioteche Email: z.tajoli(a)cineca.it Fax: 051/6132198 *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI)

8 8

Sessions terminated at random under Plack
by Magnus Enger 08 Sep '16

08 Sep '16

Dear Community, I am seeing a strange problem, and I'm not sure where to start digging. I have a (big) server with 30 odd Koha instances. One of these instances has been running under Plack for quite some time now, without any problems. Two new instances have a problem where librarians get kicked out of the intranet more or less frequently, with a message like "Your session has expired, please log in again". We had this problem on 3.22.x. After upgrading to 16.05.02 it went away. After upgrading to 16.05.03 last night it came back again. It is not consistent. Earlier today it looked like you could log in, click on a link, get thrown out, login again and then things would work. Later users got kicked out every single time they clicked on a link in the intranet. All sites are running off the official Debian packages, on the same server. Memcached is installed, enabled and used for storing sessions. Switching SessionStorage to the DB does not stop the problem. Stopping and disabling Plack for these two instances makes the problem go away. I have not found anything interesting in Plack or Apache logs. Anyone got a hunch what might be causing this? Or where to start digging? Best regards, Magnus

4 10

Reminder: General IRC meeting 7 September 2016, 20 UTC
by Katrin Fischer 06 Sep '16

06 Sep '16

Hi all, there is a general IRC meeting scheduled for 7 September, 20 UTC: https://wiki.koha-community.org/wiki/General_IRC_meeting_7_September_2016 Please make sure to add any topics you want to discuss to the agenda! Hope to see you there, Katrin

1 0

Serious problem
by Mark Tompsett 06 Sep '16

06 Sep '16

Greetings, Take the following steps: check out, check in, restart mysql server, check out, check in... old_issues bug! This is because we delete from issues (among other tables) when we move it to old_issues and "InnoDb forgets its highest auto_increment after server restart". Any ideas on the best way to solve it? Should I resurrect my https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10454 ? GPML, Mark Tompsett

5 16

A happy thought...
by Mark Tompsett 05 Sep '16

05 Sep '16

Greetings, Rather than post a problem, I thought I would actually say something positive here. I am testing a bug 11592, and decided to run all the tests ‘prove t’ and ‘prove xt’. It’s so pretty! Yes, there was some barfing verbage, but I can’t believe how clean the tests have gotten. This is great. Yes, the whole: t/00-load.t ......................... 1/? DBIx::Class::Storage::DBI::_warn_undetermined_driver(): This version of DBIC does not yet seem to supply a driver for your particular RDBMS and/or connection method ('Mock'). While we will attempt to continue anyway, the results are likely to be underwhelming. Please upgrade DBIC, and if this message does not go away, file a bugreport including the following info: { DBD => "DBD::Mock", DBD_VER => "1.45", DBIC_DRIVER => "DBIx::Class::Storage::DBI", DBIC_DSN => "DBI:Mock:", DBIC_VER => "0.082810", DBI_VER => "1.631" } DBIx::Class::Storage::DBI::sql_maker(): Your storage class (DBIx::Class::Storage::DBI) does not set sql_limit_dialect and you have not supplied an explicit limit_dialect in your connection_info. DBIC will attempt to use the GenericSubQ dialect, which works on most databases but can be (and often is) painfully slow. Please file an RT ticket against 'DBIx::Class::Storage::DBI' at /home/mtompset/kohaclone/Koha/Objects.pm line 83 is to be expected currently. The only other issue I had was: t/ImportBatch.t ..................... 1/3 Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/MARC/File/XML.pm line 397, <__ANONIO__> chunk 1. Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/MARC/File/XML.pm line 397, <__ANONIO__> chunk 1. Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/MARC/File/XML.pm line 397, <__ANONIO__> chunk 4. But everything else was nice! I remember when tests had so much strange output that it initially freaked me out. I’m glad to see we are constantly improving. GPML, Mark Tompsett

2 1

(deleted)borrowers.updated_on nullable or not ?
by Julian Maurice 05 Sep '16

05 Sep '16

Hi, I noticed that (deleted)borrowers.updated_on (introduced by bug 10459) is defined as nullable in updatedatabase.pl but not nullable in kohastructure.sql and Koha::Schema. I started writing a patch to fix this in updatedatabase.pl but I'm not sure of what should be the correct definition. Any thoughts ? -- Julian Maurice <julian.maurice(a)biblibre.com> BibLibre

1 1

Re: [Koha-devel] What's on in Koha devel #3 (RESTful API)
by Marcel de Rooy 05 Sep '16

05 Sep '16

> = RESTful API = > I also would like to know who is willing to maintain this code? For instance on bug 16330 (REST API: add routes to add, update and delete > patrons) the delete route is calling > # check if loans, reservations, debarrment, etc. before deletion! > my $res = $patron->delete > So no check is done from the API. > But if bug 16907 (Move DelMember and HandleDelBorrower to > Koha::Patron) is pushed, $patron->delete will take care of the holds, etc. My question is simple: are we expecting from devs, signoffers and > QAers to update and maintain these routes? > Or a dedicated person will update them before each release? Just formally, I would say that if the community agreed to push this code, the community should maintain it too. We should keep the code base in a consistent state. Similarly, we should prevent redundant code: the checks for deleting a patron in one place, etc. If we are on a road now creating a lot of redundant code between Koha/REST and Koha/Objects, we should re-evaluate first and not just keep pushing more code. Is this mainly a communication issue? Which goals do we want to achieve? Should our scripts go via REST some day and should all business logic remain in Objects? Etc. etc. Marcel

10 18

GBSD on 9 September!
by Katrin Fischer 04 Sep '16

04 Sep '16

Hi all, we will have a GBSD (= Global Bug Squashing Day) on 9 September. The event will last for all of 9 September, independent of the timezone you are located in, starting in Kiritimati and ending in Honolulu. You can find details about the event on the wiki: https://wiki.koha-community.org/wiki/2016-09-09_Global_bug_squashing_day If you want people to test, discuss or help with something specific during GBSD, please make sure to add your ideas under the 'Specials for this GBSD' heading on the wiki page. Hope to see you there, every little bit helps! Katrin

1 0

Koha Community Newsletter: August 2016
by kohanews 04 Sep '16

04 Sep '16

Fellow Koha users: The Koha Community Newsletter for June 2016 is here: https://koha-community.org/koha-community-newsletter-august-2016/ Many thanks to the folks who submitted articles and news to this month's newsletter. Please feel free to email me with any corrections or suggestions. Thanks! -- Chad Roseburg Editor, Koha Community Newsletter

3 2