- 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 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

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

Koha::* business objects authorization check
by Tomas Cohen Arazi 31 Aug '16

31 Aug '16

Hi everyone, adding to the discussion about Koha::Objects I have a subject that needs broad (an urgent) discussion. The REST api patches are shaping up, and I'd like to focus on an important one: 14868 [1]. This bug introduces a way of specifying on the Swagger files, the required privileges to do stuff on objects. For example: + "x-koha-authorization": { + "allow-owner": true, + "allow-guarantor": true, + "permissions": { + "borrowers": "1" + } } specifies that to get a patron object you need to either have the 'borrowers' permission, be the object owner, or the guarantor of the object's owner. This is really nice, because permissions definition are now higher level entities (just a configuration thing), and they are part of the API documentation. There's even a bug with patches that introduce required permissions in the error messages. The current implementation introduces checks for each object class on the controller code. My feeling is that each business object should be responsible for such a check. The first step I made was to extend Koha::Object so it exposes an ->owner method that returns the Koha::Patron object that owns the object (because we can get the guarantees from there too). I did this to eliminate the need of class-specific checks on the controller. But at the end of the day, this still didn't feel it was good enough. I belive such a business matter should not be so tied to the controller/routing code and it is still there. Talking with Jonathan we thought we could make Koha::Objects->search accept more parameters (current userid, required permissions) and have the code checking authorization there, basically creating a filter on the search. The main problem is how to propagate the swagger-specified required permissions down to the Koha::Object in a clean way. I'd like to hear how people belive we should handle on this new+fresh code permissions check, so we have good foundations for the future of the project. Cleaning untested business logic from controller scripts is a good start! And this is the time to do it! Thanks in advance PS. I'm sure Jonathan will explain the discussion better once he comes back from the pub :-D [1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14868 -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F

3 4

biblioitems.marcxml & biblioitems.marc / HUGE performance issue !
by Paul Poulain 31 Aug '16

31 Aug '16

Hi all, Those days, we're working on a pretty large DB ( >1M biblio), for a customer that want to do many statistics on some fields. We discovered that something "simple" like: SELECT publicationyear, count(publicationyear) FROM biblioitems GROUP BY publicationyear; was giving *no result in 10mn*. This is a test DB, not optimized, but we were surprised by the results. After investigating we had the idea to create a biblioitems2 table with the same structure *EXCEPT MARCXML and MARC fields *launch the same SQL query : *result in 3seconds* !* *This could be reproduced on any query (on fields without index). I think it's because the innoDB is storing each line in one "object", so, even if you need only one column, you have to read everything. In our case, that was 12GB+ of data to read. biblioitems2 is just a few dozen MB. (all caching values are minimum and there's no index, so not involved in the results) MY CONCLUSIONS: * the biblioitems.marc field must be removed quickly: it's useless since years, and is only resulting in slowing things * the bilbioitems.marcxml field should be moved outside from this table. Something like biblio_blob, with biblionumber, biblioitemnumber and marcxml. When we need it, just join the tables. I'm almost sure it would have an important impact on Koha, as biblioitems table is called and used "everywhere". any opinion ? ** -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries

6 7

GoogleIndicTransliteration must die?
by Indranil Das Gupta 31 Aug '16

31 Aug '16

Hi all, Koha uses the deprecated (in 2011) Google Indic Transliterate v1 API to power the GoogleIndicTransliterate syspref. It seems internally the API calls to Googe Inputtools service over http! So again we are back in MIXED CONTENT mess and nothing much we can do about it, except move out of this API. transliteration.I.js:formatted:11055 Mixed Content: The page at 'https://rksmvvlibrary.in/cgi-bin/koha/opac-search.pl?q=%E0%A6%B6%E0%A7%8D%E…' was loaded over HTTPS, but requested an insecure script 'http://www.google.com/inputtools/request?text=shyama&ime=transliteration_en…'. This request has been blocked; the content must be served over HTTPS.Q.dh @ transliteration.I.js:formatted:11055Ww @ transliteration.I.js:formatted:4578Q.Ad @ transliteration.I.js:formatted:10982(anonymous function) @ transliteration.I.js:formatted:11237(anonymous function) @ transliteration.I.js:formatted:6670(anonymous function) @ transliteration.I.js:formatted:6059nq @ transliteration.I.js:formatted:2266(anonymous function) @ transliteration.I.js:formatted:6232a @ transliteration.I.js:formatted:6074 transliteration.I.js:formatted:10923 Uncaught TypeError: Cannot read property '0' of nullQ.Bh @ transliteration.I.js:formatted:10923Q.Mi @ transliteration.I.js:formatted:10862Mt.(anonymous function).j @ transliteration.I.js:formatted:8324(anonymous function) @ transliteration.I.js:formatted:3591 I saw this http://stackoverflow.com/questions/35238710/deprecated-google-api-will-not-… and this https://groups.google.com/forum/?fromgroups#!topic/google-ajax-search-api/9… Looks like its time to bid goodbye to GoogleIndicTransliteration syspref :-( -- Indranil Das Gupta L2C2 Technologies Phone : +91-98300-20971 Blog : http://blog.l2c2.co.in IRC : indradg on irc://irc.freenode.net Twitter : indradg

2 1