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

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 05 Sep '16

05 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

Release unification: Security fixes and releases
by Mirko Tietgen 04 Sep '16

04 Sep '16

Hello everyone, can we maybe find a consistent way of labelling releases/ fixes "security"? All new releases contain XSS patches… - 3.20 and 3.22 are labelled "security release" in the emails/ release notes - 16.05 is not - 16.05 and 3.20 list the fixes under the headline "Critical bugs/ Koha - 3.22 as "Security bugs fixed" on top of the list - 3.22 features "security" in the release notes headline (and so in the URL in Wordpress) - The others don't The first question is probably… - Is a security release only a special release in between the regular schedule or - is a security release everything that contains patches with security fixes? It seems to me that the second option is more common within the Koha community and personally I'd prefer it. We should shout it at people and make them upgrade. To underline that intention, showing the security fixes seperately on top of the release notes makes sense to me. I propose to… - use the label "security release" in the release notes headline and first paragraph (and Wordpress URL) - mention number of security fixes seperately - display them under the headline "Security bugs fixed" on top of the list …whenever there are patches from "Koha security" in a release. Basically that is what we have in the 3.22.10 release notes: https://koha-community.org/koha-3-22-10-security-release/ Does that make sense? Any reasons not to do it? Is it harming artistic freedom of RMaints? Would it complicate stuff a lot? I think it would be a good thing to have some consistency here. Cheers, Mirko -- Mirko Tietgen mirko(a)abunchofthings.net http://koha.abunchofthings.net http://meinkoha.de

4 4