[Koha-devel] What's on in Koha devel #3

[Jonathan Druart]

Hi devs,

Lot of things have been going on during the last month and lot of patches
are in the queue :)

= Security issues =
Plenty of security issues have been raised and fixed during the last
month (and others are still coming). They are related to CSRF and XSS
protections.
See bug 14568 ([OMNIBUS] XSS in Staff Client) and
bug 17096 ([OMIBUS] CSRF protections) for the entry points. Most of
them are in the security project and most of you won't have read
access, but if you are interested in testing them you can ask someone
on #koha to have access.

= Caching system =
If you are familiar with plack and memcache, please have a look at the
POC on bug 16579 (Use separate memcached namespace for caching
koha-conf.xml). No need to test it if you don't want, you can just
have a glance at it.

= RESTful API =
A lot of patches related to the RESTful API are in the SO and QA queues.
The actors (authors/signoffers) are almost always the same.
I'd like to know if someone (from the QA team or not) fancy to
technically review these patches.
I did not follow closely the discussions and the progress of the
RESTful API and I think it could be good to have someone who's implied since
the beginning in the QA process to have a look at how the architecture
is done.
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?

= Focus on blockers =
When criticals or blockers are opened, usually it takes between 3 or 4
days to get a patch and see it pushed. Which is quite fast :)
But most of the time, several bug reports are opened meanwhile
and marked as duplicate later.
So I think we should focus as much as possible on signing off these
patches and 1/ ask on #koha if you find a software error and 2/ Search
on the bug tracker in the most recent bugs.
For instance bug 16960 (critical) has a patch waiting for a signoff
for 3 days now...

= Refactoring =

Lot of things to say here :)

== Accounts rewrite ==
I'd like to start QAing some parts of the accounts rewrite.
For instance bug 15899 (Remove the use of recordpayment) is a good
first candidate. But to do so I need all the dependencies to be signed
off.

== Koha::Patrons ==
Lot of things have been moved last month, the entry point is bug 16846
(Move patron related code to Koha::Patron) if you want to help or just
have a look.

== C4::Branch is (almost) dead ==
Bug 15758 (Move the C4::Branch related code to Koha::Libraries - part
4) removes completely C4::Branch. It is a big patch and has been
widely tested.
We need a quick but deep QA here, it's a nightmare to rebase!

== Koha::AuthorisedValues ==
(I have c/p the following on bug 15799 - Move authorised values
related code into Koha::AuthorisedValues - part 2, better to comment
on the bug report)

We have already started to move the authorised values related code to
the Koha namespace, but some are still missing.
To continue and move C4::Koha::*AuthorisedValues* subroutines to
Koha::AuthorisedValues, we will need to join on
marc_subfield_structure(.authorised_value which is actually an
authorised value category).
To do so we need to define a relationship (fk) between the two tables.
But we have "special AV" like Asort1 (and friends) , LOST, DAMAGED, etc.)
Which could not be in the authorised_values table [yet]. And 3 other
"special special AV) like itemtypes, branches and cn_source.
Others (undetermined so far) are linked to a marc_subfield_structure
from installer/**/marcflavour/**/*framework*.sql, like STACK.
My idea would be to move all the AV categories to a new table
authorised_value_categories. It will contain only 1 column
category_name refered by 1. authorised_values.category, 2.
additional_fields.authorised_value_category (others authorised_value
field should be renamed like that when they refer AV categories) and
3. iitems_search_fields.authorised_value_category.
And, maybe later, auth_subfield_structure, auth_tag_structure,
borrower_attribute_types, marc_tag_structure (some are varchar(10) et
20 when they should be 32!)
We could imagine more attributes to this table, but don't ask me to
add a authorised_value_categories.id as pk please :)
We will have to use temporary tables to deal with the DB constraints,
to add more fun.
Finally the .sql will have to be updated to reflect these changes.
I have just started but before to enter in this tunnel I'd like to
know if there are a couple of volunteers to test? :)

= Ubuntu 16.04/MySQL 5.7 support =
Note that we are still waiting for bug 16554 to support Ubuntu 16.04
and MySQL 5.7 out of the box.

A dev meeting is planned on August 24th at 7 UTC
(https://wiki.koha-community.org/wiki/Development_IRC_meeting_24_August_2016).
Please have a look at the agenda and the different topics we will
discuss.

Don't forget to register for the Hackfest in Marseille in October
(http://lists.koha-community.org/pipermail/koha-devel/2016-June/042790.html)

Cheers,
Jonathan