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

Please help clean up bugs on unmaintained branches
by Owen Leonard 12 Aug '16

12 Aug '16

Recently I've been going through the list of bugs reports on unmaintained 3.x versions of Koha. I've closed bugs which I could not verify and updated to 'master' those which I could reproduce. The list is down to 45 bugs which I had questions about, didn't understand, or didn't know how to test. I would love to get help getting that list down to zero. Please take a look if you can. https://bugs.koha-community.org/bugzilla3/buglist.cgi?cmdtype=runnamed&name… Thanks, Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

1 1

Koha::Object[s] improvements - call for discussions
by Jonathan Druart 11 Aug '16

11 Aug '16

Hi devs, At the KohaCon16 some of us have briefly talked about the limitations of Koha::Object[s] we encounter when implementing new modules. Koha::Object[s] has been pushed to master less than 18 months ago and we already have more than 30 classes using it. It permits to uniformise our way to code, use powerful objects and is very easy for refactoring. I have been moving code from C4 to the Koha namespace and it's very handy to just have to write a concise module and automatically have the basic methods (CRUD and more). However it seems that we need to clearly define what we need in a near future and adapt it quickly if it's needed. = Rooms for Improvement = There are 3 main rooms for improvement: - DBIx::Class basic methods - DBIx::Class relationship accesses - Koha::Objects vs DBIx::Class objects == DBIx::Class basic methods == If you want to access a method provided by DBIx::Class, like ->store, ->delete, ->is_changed, we need to create a silly method which just calls the same method on the DBIx::Class object. For instance, let's take Koha::Objects->is_changed sub is_changed { my ( $self, @columns ) = @_; return $self->_result()->is_changed(@columns); } Possible solution: It would be possible to modify our AUTOLOAD method and check if it's a DBIX::Class method. If it is a valid one, let's call it, otherwise carp something. == DBIx::Class relationships == >From a Koha::Objects, the relationships provided by DBIx::Class will not be automatically generated. For instance, from a virtual shelf, you will not have access to the items on the shelf. You will have to create a method which will call the DBIx::Class relevant relationship. sub get_contents { my ( $self ) = @_; my $contents = $self->{_result}->virtualshelfcontents; return $contents; } This piece of code adds a get_contents method to Koha::Virtualshelf and call the virtualshelfcontents relationship created by DBIx::Class. Note that this is finally good here, it is better to call have a get_contents method than virtualshelfcontents. But we may prefer to redefine it in the schema file (Koha::Schema::Result::Virtualshelve). Possible solution: Same as previously, it would be possible to modify our AUTOLOAD method and check if it's a valid relationship. == Koha::Objects vs DBIX::Class objects == We'd like to always manipulate the same kind of objects, to avoid confusion when reading the code. At the moment we already manipulate 2 different entities: hashref from C4 and objects from Koha::Object. It's confusing and not so easy to manage in the code. To add flexibility we have added a Koha::Object->unblessed method to transform the object to an hashref, it's not ideal but it ease the transition. Anyway, from a Koha::Object if you want to retrieve data linked to this object, you would like to get a Koha::Object object base, not a DBIx::Class object base. If we continue with the previous example, we will need to modify get_contents like this: sub get_contents { my ( $self ) = @_; my $rs = $self->{_result}->virtualshelfcontents; my $contents = Koha::Virtualshelfcontents->_new_from_dbic( $rs ); return $contents; } Basically ->new_from_dbic will just create an empty Koha::Virtualshelfcontents object and set the internal resultset. No query or extra processing should be done here. I do not know if the changes suggested (and already implemented in some areas and patches in the queue) is consistent. It's not very elegant to read, but it looks safe on the performance side, despite the encapsulation problem we could see at first glance. = Concerns = == API == Some people raised concerns about the new API to lean. But finally we stick on DBIx::Class method names, so it should not be to hard to learn for new devs. And... the modules in the Koha namespace are much more easier to read/understand than the legacy code in C4. == ResultSet == It seems that writing the following is not obvious for everybody: # Create and store my $biblio = Koha::Biblio->new( { title => "a title", [other => $data] } ); $biblio->store; # Retrieve data my $biblio = Koha::Biblios->find( $biblionumber ); my $biblio = Koha::Biblios->search( { title => "a title" }); # Access relationship my $items = $biblio->items; warn ref( $items ); # Koha::Items warn ref( $items->first ); # Koha::Item This looks very easy to read for me, feel free to suggest something else. = A complete example = At the moment, the more complete example in master (and 16.05) is the Koha::Virtualshelf and Koha::Virtualshelves modules. It includes several search methods, overwrite of the store method and some complex methods as well as complete test coverage (t/db_dependent/Virtualshelves.t) = Alternatives = If you think you can provide an alternative or an idea to improve/replace our Koha::Object[s] implementation, do not hesitate, I would be glad to review or even implement it! If you want to discuss one of these point, add a new one, or have a specific question, please answer this email. We could talk about that during the next dev meeting as well. Cheers, Jonathan

4 5

Koha namespace architecture - calls for discussions
by Jonathan Druart 11 Aug '16

11 Aug '16

Hi devs (me again), During the last dev meeting, we discussed about the naming of a new module in our Koha namespace. The conclusion was to ask the ML in order to get more ideas (as there was not a lot of attendees...). I'd like to take this opportunity to bring other architecture problems I faced recently (Bug 16846 - Move patron related code to Koha::Patron). 1/ Import stuffs modules The initial discussion comes from 2 modules which have been added in 2 different bug reports about the same thought [1]. To provide a module to import patron, the author of bug 12598 chose Koha::Patrons::Import when I chose Koha::Exporter::Record on bug 14722 (the first one is about importing patrons, the second one is about exporting records (biblios, authorities)). We need to uniformise these 2 namespaces to keep consistency. The different possibilities are: a. Koha::Patrons::Import b. Koha::Importer::Patrons c. Koha::Importer::Patron d. Koha::Import::Patrons e. Koha::Import::Patron My opinion is that having Koha::Exporter|Importer::Objects will add the ability to have a Koha::Exporter|Importer module to group export/import methods, if we want to (Objects means Patrons, Records, Lists(Shelves), Reports, etc.) But we could imagine a generic Koha::Exporter|Importer modules with specific Koha::Object[s?]::Export|Import modules. 2/ Move C4::Members::GetBorrowersWithIssuesHistoryOlderThan to the Koha namespace This subroutine is supposed to return the patrons with an issue history older than a given date. I first chose to move this code to Koha::Patrons->search_with_issues_history_older_than But looking at the code you will find that the subroutine actually returns the borrowernumber with the number of old issues (matching the "older than" date). IMO it would make sense to return the patrons (Koha::Patron) instead of just the borrowernumber, but we will have to join the 2 tables, which can lead to a perf issue (ref needed). This idea is enforced by the fact that GetBorrowersWhoHaveNeverBorrowed and GetBorrowersToExpunge fit perfectly into Koha::Patrons. Otherwise we could decide to move the subroutine to a method of Koha::OldIssues, to avoid the join. But that sounds weird to me. 3/ Move C4::Ratings I have started to move C4::Ratings to Koha::Rating[s] Everything went fine until I decided to move C4::Rating::GetRating. It actually calculates the ratings avg for a record and returns a hashref with different values, and not a Koha::Rating object. I think we need to split up with Koha::Ratings->search({ biblionumber => $biblionumber })->calculate_avg (or something similar) and Koha::Ratings->search({ biblionumber => $biblionumber, borrowernumber => $borrowernumber }); # which will return a Koha::Rating object In that case, 1 call to C4::Ratings::GetRating will be replaced with 2 calls. Does that make sense? 4/ Move subroutines not directly related to a Koha::Object In some cases, the move is not very obvious. For instance we have C4::Members::checkcardnumber and C4::Members::get_cardnumber_length, they are strongly linked and I think we would like to keep them together. We could imagine a Koha::Patron::Cardnumber to move get_cardnumber_length in, but it does not represent a patron's cardnumber, so it could be confusing. checkcardnumber could go easily to Koha::Patron->check_new_cardnumber( $new_cardnumber ) 5/ patronflags? Any ideas what we could do with C4::Members::patronflags? :) Others will certainly come later! Cheers, Jonathan [1] http://meetings.koha-community.org/2016/development_irc_meeting_13_july_201… from 14:29:48 <cait> #info Topic: Koha::Patrons::Import (bug 12598) vs Koha::Exporter::Record (bug 14722)

4 4

Reminder: Koha Development IRC meeting - 19 UTC
by Katrin Fischer 09 Aug '16

09 Aug '16

Hi all, there is a Development IRC meeting scheduled for 10 August at 19 UTC. The agenda can as always be found on the wiki: https://wiki.koha-community.org/wiki/Development_IRC_meeting_10_August_2016 Please add the topics you want to discuss to the agenda! Hope to see you there, Katrin

1 0

Introducing Koha nightly packages
by Mirko Tietgen 08 Aug '16

08 Aug '16

Hello dev people, I have set up a build server and repository for automatic Koha nightly builds (Debian packages) of master, 16.05.x and 3.22.x. It also serves a live installation running the latest master build, unless it is broken. You can find it at https://apt.abunchofthings.net/koha-nightly/ Friendly word of advice: Kids, do not use this in production. It's just a development toy. Cheers, Mirko -- Mirko Tietgen mirko(a)abunchofthings.net http://koha.abunchofthings.net http://meinkoha.de

2 1

Signoff request: bug 16929
by Marcel de Rooy 08 Aug '16

08 Aug '16

Hi all, Just rebased bug 16929. Two pending security fixes depend on this report. Not hard to test. I already verified that it resolves a possible delay on some virtual servers. If you do not experience that delay, your signoff still serves to assure that the script is working properly. Please add your signoff to get this further. Thanks, Marcel PS As a sidenote, there is still another problem with opac-memberentry. It is addressed on bug 16960.

1 0

Re: [Koha-devel] [Koha] General IRC Meeting 3 August 2016 / Kohacon 2017 bidder information
by Chris Cormack 03 Aug '16

03 Aug '16

On 3 August 2016 at 21:36, Joann Ransom <joann.ransom(a)gmail.com> wrote: > Is it too soon to bid KohaCon 2019 for NZ ? > We had 2010, how about 2020 to keep it round numbers :) Chris

1 1

Regarding the implementation of recommender system in koha
by ADITYA RAJ 03 Aug '16

03 Aug '16

Sir,In my college I am working on recommender system project and I want to implement it in koha search so I need some help Hoping positive response from you

2 1

Biblibre sandboxes out
by Fridolin SOMERS 03 Aug '16

03 Aug '16

Hie, Our sandboxes are broken (lets say on holiday) : https://wiki.koha-community.org/wiki/Sandboxes#BibLibre This is because there is a new dependency only existing since Jessie, and those machines can not upgrade. We are migrating all our servers to Ubuntu Xenial. We will tell you when sandboxes are done. Best regards, -- Fridolin SOMERS Biblibre - Pôles support et système fridolin.somers(a)biblibre.com

1 0

General IRC Meeting 3 August 2016 / Kohacon 2017 bidder information
by Mirko Tietgen 03 Aug '16

03 Aug '16

Hi everyone, the next general IRC meeting is next week, 3 August 2016, 10:00 UTC. Conversion to your local time: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+IRC+General+M… You can find the agenda here: https://wiki.koha-community.org/wiki/General_IRC_meeting_3_August_2016 This is the last meeting before we close bidding to host Kohacon 2017. It would be nice if bidders would join us at the meeting and tell a little about their plans. If the meeting is not an option, please send a message to the mailing list explaining that you are still interested in hosting Kohacon 2017, and please update your proposals in the Koha wiki now if necessary: Narrow down the proposed dates if possible, update conference locations, add contact emails(!). https://wiki.koha-community.org/wiki/KohaCon17_Proposals We are still open for proposals to host Kohacon 2017 until 10 August 2016 UTC. Cheers, Mirko -- Mirko Tietgen mirko(a)abunchofthings.net http://koha.abunchofthings.net http://meinkoha.de

5 5