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

[Tomas Cohen Arazi]

Jonathan, nice overview!

El jue., 11 ago. 2016 a las 9:09, Jonathan Druart (<
jonathan.druart at bugs.koha-community.org>) escribió:

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

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

I'll try to!


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

Until 17044 and 17030, the REST api was of no use for the general public.
Right now, it will start being available and this bugs should be reported.
Ultimately, the 'routes' could be used for replacing the controller scripts
on some portions of the UI, so they should respect the behaviour from the
present scripts regarding this kind of things. Maybe we should recommend
devs to write routes only on top of already migrated libs (moved to Koha::
namespace). Anyway, lets write those routes! And push them!


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

Awesome!


> == 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
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
-- 
Tomás Cohen Arazi
Theke Solutions (https://theke.io <http://theke.io/>)
✆ +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160812/e4c3498f/attachment.html>