14:14:18 <tcohen> #startmeeting Development IRC meeting 26 August 2015 - part 1
14:14:18 <huginn> Meeting started Wed Aug 26 14:14:18 2015 UTC.  The chair is tcohen. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:14:18 <huginn> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:14:18 <huginn> The meeting name has been set to 'development_irc_meeting_26_august_2015___part_1'
14:14:25 <tcohen> #topic Introductions
14:14:25 <wahanui> #info wahanui, a bot that has become sentient
14:14:33 <tcohen> please introduce yourself with #info
14:14:42 <tcohen> #info Tomas Cohen Arazi, Theke Solutions
14:14:46 <Joubu> #info Jonathan Druart, UK
14:14:57 <marcelr> #info Marcel
14:14:58 <jajm> #info Julian Maurice, BibLibre
14:15:16 <nengard> #info Nicole Engard, ByWater Solutions
14:15:54 <tcohen> will wait a couple more minutes
14:15:59 <tcohen> for others to join
14:16:18 <huginn> New commit(s) kohagit: Bug 11190: sitemap.pl -- Generate a Catalog sitemap <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=ca341f6840ad7eb9170ce49f1ed6869b3e468297> / Bug 14557: Add holds count to holds tab <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=cc79ab3cdd42513fa46a7f78c03282625543d6f5> / Bug 14557: Clean up biblio-view-menu.inc <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=a3b7f059a1f95945bcb5bbc1123b8eead17433fc> / Bug 14714: Add tab-completion to koha-mysql command <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=55a52c1218a672dc770b9f0cf4e20501f73ba153> / Bug 14361: koha-restart-zebra fails and probably breaks upgrade <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=e09e7152b6af1f2cb3d2e78eff317cdf77cbf5f2> / Bug 12632: (regression tests) Unit Tests <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=34c11ee8eee5a547de3a83c2cba8e6eeedecfa01> / Bug 12632: Hold limits ignored for record level holds with item level itemtypes <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=6f95acd1a6cf5113992d28173dece96e8afc6cef> / Bug 7143: Add Benjamin Rokseth to the projects history file and about page <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=3e1282b135cb642e8dac90f810edb5f29889e85e> / Bug 7143: spaces in history.txt instead of tabs break display on website <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=c9234cb92ddd9ec1ec19e399c185e1ba9b11a9d9> / Bug 9809: DBRev 3.21.00.19 <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=1bf5fb920bc34f44706e837dd1b7441381146eb3> / Bug 9809: Remove one more occurrence of reserveconstraints <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=eaff67140c5607232b64f29cb3530b3c8655f024> / Bug 9809: Fix pod errors <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=64fcab9e518c16613c98095bd6a08d76fda20e8f> / Bug 9809: [QA Follow-up] Still found some remains <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=092a7e1b531f4de5218fe7136d4e646a845aaad4> / Bug 9809: [QA Follow-up] Remove constrainttype from 14464 tests <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=031a3196a49dd5fba98aa6c7b7cea299a312005e> / Bug 9809: [QA Follow-up] Remove an erroneous call to GetReserveFee <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=b7119848850c8bb44cb933d7b07d8582a761a181> / Bug 9809: [QA Follow-up] Remove warnings from Hold.pm <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=71ce0d96c9d72571e45c568acb7aab321a42009b> / Bug 9809: Update AddReserve prototype to remove constraint parameter <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=ad3239479db4e5542a6f29bfd1bb1af9187ac67b> / Bug 9809: Remove reserveconstraints references from C4::Reserves <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=a3795250862da29d32b124bfe18ca37b53888c79> / Bug 9809: Update unit tests <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=76f16b1b42ded69fb9c9672bbeb7a92203783fe5> / Bug 9809: Remove DBIC module for reserveconstraints <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=4251d4f8822999d7b5d442d9e4ae86941ae67e06>
14:16:35 <tcohen> huginn: shh, meeting
14:16:35 <huginn> tcohen: downloading the Perl source
14:16:42 <tajoli> #info Zeno Tajoli, Cineca, Italy
14:16:49 <drojf> #info mirko tietgen, berlin, germany
14:18:22 <tcohen> ok, i think that's all
14:18:32 <tcohen> khall_dnd: ?
14:18:47 <tcohen> ashimema?
14:18:48 <wahanui> rumour has it ashimema is on qa now .)
14:18:51 <khall_dnd> #info Kyle M Hall, ByWater Solutions
14:18:57 <Joubu> dnd is for dungeon and dragon, isn't it?
14:19:04 <tcohen> yeah, he's distracted
14:19:12 <marcelr> no longer
14:19:13 <tcohen> ok, moving on then
14:19:15 <khall> ; )
14:19:20 <tcohen> #topic RM 3.22 comments
14:19:28 <tcohen> please RM, speak
14:19:37 <tcohen> not here? ok, moving on
14:20:24 <tcohen> #info some important sutff has been pushed recently, notably plack integration for packages and the sitemap building tool contributed by Tamil
14:21:05 <tcohen> #info I hope all of you have the chance to take a look to the plack integrating scripts, so we have them tuned for the release
14:21:55 <tcohen> #action the RM will send a pull request for kohadevbox to be adapted to this new scripts
14:23:18 <tcohen> #info Koha::Logger has been pushed too, and it is expected that new devs use it, while we don't enforce such things.
14:23:40 <marcelr> is there some rule for using Koha::Logger?
14:23:41 <tcohen> please ask here on IRC for help if you have doubts on how to use it
14:23:46 <Joubu> Koha::Logger: it would be great to have a coding guideline about how to use it
14:23:49 <marcelr> yes
14:23:56 <tcohen> yes, I agree 100%
14:24:18 <tcohen> khall: you wrote a piece of text on the wiki on how to use it, right?
14:24:44 <marcelr> if khall writes that rule, that would be great :)
14:24:45 <khall> tcohen: I'm not sure, I'll have to refresh my memory. If I haven't I'll be sure to do so!
14:25:10 <khall> I think I've only done a wiki page for Koha::Object
14:25:15 <Joubu> see comments on http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14597#c6
14:25:16 <huginn> 04Bug 14597: major, P5 - low, ---, kyle, Signed Off , Reverting a batch where a record overlaid is now deleted record will fail
14:25:35 <tajoli> also an article on koha newletter ?
14:26:08 <tcohen> good idea tajoli
14:27:00 <tcohen> khall: would you write something we could vote on a next dev meeting? (sooner than this one)
14:27:11 <khall> absolutely!
14:27:34 <tcohen> #action Kyle will write a proposal for adding the use of Koha::Logger to the coding guidelines
14:27:51 <tcohen> questions?
14:27:51 <wahanui> questions are good :)
14:27:57 <tcohen> I expect questions on plack
14:28:16 <tcohen> we really need testing
14:29:10 <tcohen> is anyone using kohadevbox for testing here?
14:29:23 <Joubu> not yet, will do soon
14:29:46 <tajoli> For test I use dev install
14:30:22 <tcohen> maybe we could do some tutorial during the next GBSD
14:31:12 <tcohen> ok, i'll move faster so we get to the main topic
14:31:48 <tcohen> i've been trying to keep my queue low, taking on bugs as a higher priority, and trying to push older stuff first
14:32:07 <marcelr> tcohen++
14:32:21 <tcohen> i remind you that if i ommit something it is not on purpose, so please tell me if you feel your work has been lagging on my queue
14:33:24 <tcohen> i'm trying not to get bored with the amount of boureaucratic work the RM tasks mean, so I've been coding stuff myself so i splitted my time (sort of) between small devs and the RM duties
14:33:53 <tcohen> at this time of the year, when lots of people are on vacation, it is difficult to keep the pace and have things moving on
14:34:08 <tcohen> this is a personal comment, but i want you to know that
14:34:23 <tcohen> it is a lot of work and too little fellows around
14:34:34 <tcohen> that's why i've been writing tab-completion patches and such
14:34:43 <tcohen> to stay focused on something fun
14:34:44 <tcohen> heh
14:34:45 <tcohen> ok
14:34:56 <drojf> fun++
14:35:00 <tajoli> I confirm that in Italy August is vacation month
14:35:17 <tcohen> as usual, let me know anything that is bothering or worrying you. better earlier than late
14:35:46 <tcohen> any other comments on my comments?
14:36:17 <tcohen> #topic RESTful API Implementation
14:36:34 <tcohen> work on this topic is sort of stuck right now
14:36:57 <tcohen> the point of this meeting was to talk about it, and try to figure what needs to be done to unlock that development
14:37:25 <tcohen> from the very beggining, the use of a web framework like Mojolicious has been subject of some criticism
14:38:04 <tcohen> we are not yet at a point where the results are in clear favour of using the framework, that's my opinion
14:38:17 <tcohen> while I am in favour of adopting Mojolicious
14:38:31 <tcohen> so, i support that implementation basis
14:39:16 <tcohen> my personal opinion is that the work that's been done was focused on one use-case, system<->system communication (hence the API key stuff)
14:40:00 <tcohen> and once the rest of us mentioned that integrating the use of CGISESSID and the rest of Koha's permission system into it
14:40:13 <tcohen> we got to a halt situation
14:41:03 <tcohen> Olli said it would be difficult to do with the current authentication API, and went all into rewriting (Koha heh) the Auth code
14:41:28 <ashimema> I've been MIA for a while I'm afraid, and will continue to be unfortunately for a little longer.. too much on my plate at the minute to get to grips with these re-writes :(
14:41:36 <ashimema> so.. apologies for little to no comments
14:41:51 <khall> I believe that the RESTful API needs to function for external access, and within Koha itself. If we don't use it in Koha, we'll be reinventing the wheel for any ajax work we do, and likely the API will not get well maintained
14:42:25 <tcohen> khall: exactly, that's why this was raised in the previous REST meeting
14:42:52 <jajm> does someone have looked at Olli's work ? i didn't have time to do so yet
14:43:36 <tcohen> is there a possibility that we integrate the current permissions checking code into the code jajm wrote with Mojo?
14:43:41 <ashimema> not in detail jajm.. it's a big piece
14:43:45 <khall> I've seen it and it look very nice
14:43:50 <tajoli> Olli work on Auth is based on many add on Koha::
14:44:05 <fridolin> I've had a look at Auth rewrite, looks very nice an object oriented code. But I cant say if its correct
14:45:04 <tcohen> it is a pity he's not around today, because i'd like him to remind us how he ended convincing himself the rewrite was the only way to go
14:45:41 <tajoli> See graph of dependeces from this bug: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13995
14:45:42 <huginn> 04Bug 13995: enhancement, P5 - low, ---, olli-antti.kivilahti, Needs Signoff , Proper Exception handling
14:45:59 <Joubu> and be scary
14:46:43 <tajoli> I think it is a good work but there are many assuption on dependeces and evolution of Koha code into Koha::
14:47:00 <tcohen> my feeling is that we should be able to hook the CGISESSID authentication and permission checking with the current API, in a non-fancy way, while we (step by step) re-do the authentication code
14:47:17 <tajoli> Many new pieces of code
14:47:21 <Joubu> The main problem, imo is that a lot of technical choices have been done, but without any consensus/discussion
14:47:44 <Joubu> if we continue in this direction, we'll never see something pushed for the next X years
14:47:49 <Joubu> (with X > 3)
14:48:00 <tcohen> Joubu: can u elaborate? (i assume you mean not only Mojo adoption)
14:48:08 <tajoli> exactlym this the problem "lot of technical choices have been done, but without any consensus/discussion"
14:48:13 <Joubu> I mean Olli's work
14:48:39 <tcohen> ok
14:48:48 <Joubu> The discussion has been done some months ago, and now we got several implementations
14:49:05 <Joubu> but nobody discuss and people does not work together
14:49:13 <tcohen> could we improvise a list of that decisions?
14:49:18 <tcohen> i can start:
14:49:26 <tcohen> - Exception handling
14:49:56 <tcohen> (i've seen code from Olli and Jonathan that is not exactly similar, but on the same direction)
14:50:03 <Joubu> (quite the same)
14:50:30 <tcohen> olli's introduces several (too many) files for each exception, Jonathan's puts all of them in a single file
14:50:58 <tcohen> but when people looks at olli's patch, they just get scared by how many new classes are introduced
14:51:04 <khall> I think we could take a middle road between all exceptions in one file, and one file per exceptions. I think one file per module's exceptions would be good
14:51:17 <tcohen> khall++
14:52:16 <Joubu> this point is certainly is less important :)
14:52:23 <jajm> what is the bug number of Joubu's exceptions ?
14:52:23 <Joubu> the*
14:52:27 <Joubu> bug 14544
14:52:28 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14544 enhancement, P5 - low, ---, jonathan.druart, Needs Signoff , Move the list related code to Koha::Virtualshelves
14:52:33 <Joubu> somewhere in one patch
14:52:44 <jajm> thx
14:53:27 <Joubu> (http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=41958&action=edit)
14:54:12 <tcohen> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=41958
14:54:18 <tcohen> oops
14:54:48 <tcohen> 'description => "poeut"'
14:54:55 <jajm> i think the number of files doesn't matter, and with khall proposal won't we have to define what a module is ?
14:55:38 <Joubu> yes, agreed, there is no decision or discussion to get/have on this subject
14:55:52 <tcohen> i think we should have Koha::Exceptions for general ones, and the Koha::Exceptions::<Package> on a as-needed basis
14:56:07 <jajm> but do everyone agree on using exceptions ?
14:56:08 <tcohen> anyway
14:56:24 <khall> tcohen++
14:56:41 <tcohen> khall: it was your idea :-D
14:56:52 <khall> : )
14:57:07 <khall> jajm: I sure do. Does anyone *reject* the idea of using exceptions?
14:57:18 <tcohen> Joubu et al, can we try to create a list of implicit design decisions beside the use of Class::Exception?
14:57:46 <Joubu> tcohen: mine is on the list rewrite
14:57:50 <Joubu> bug
14:58:50 <Joubu> pm raises an exception, the pl sent it to the tt and the templates show a specific message
14:59:05 <Joubu> not sure we can have several ways to do :)
14:59:06 <jajm> khall, i do not reject the idea, i'm not used to exceptions and a little afraid to have try/catch everywhere
14:59:28 <Joubu> jajm: not everywhere, just at the right places
14:59:35 <tcohen> Joubu: If we suggest Olli to colapse his general purpose exceptions into Koha::Exceptions, and you reuse them and add your package specific ones into a separate package, do u think it could work?
14:59:39 <khall> jajm, it will be a much cleaner approach to error handling in the long run. You can catch an exception at any point in the call chain
15:00:02 <Joubu> tcohen: yep
15:00:46 <tcohen> jajm: we already have if (!defined $something) { short_circuit_with_some_output_to_tt } else { move_on } everywhere
15:01:17 <tcohen> anyway, so we focus on the main subject
15:01:42 <tcohen> we found a design decision that needs to be discussed and consensus found before it can be pushed
15:02:12 <tcohen> the first thing is to reach a middle road approach so we at least look consistent
15:02:49 <tcohen> i will ask Olli and Jonathan to cooperate to have a single implementation, and we will discuss it on the next dev meeting, trying to reach some consensus about it, ok?
15:03:04 <khall> sounds good!
15:03:25 <tcohen> could we try to find another decisions that are implicitly made and should be discussed in the open?
15:03:53 <Joubu> I don't think it's worth to block the list rewrite, for instance(:p), where just renaming the file could be done later
15:04:08 <khall> I agree
15:04:13 <grharry> Does anyone know why when  the idzebra binaries 2.0.60-1 from indexdata are used ... all facets disappear from the OPAC ??
15:04:25 <tcohen> because we have this workflow in which if someone doesn't like it, he/she doesn't get involved, and no decision is made, maybe we should work on that issues
15:04:40 <tcohen> grharry: later, we are having a meeting right now
15:04:44 <khall> tcohen: what about the auth refactoring? is that a discussion for now or later?
15:05:17 <Joubu> bug 7174
15:05:18 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7174 enhancement, P5 - low, ---, olli-antti.kivilahti, Needs Signoff , Authentication rewriting
15:05:21 <tcohen> khall: i think we need to discuss if that rewrite would be mandatory for the REST work or not
15:05:40 <khall> ok, that makes sense
15:05:41 <tcohen> jajm: what's your feeling about it?
15:06:37 <khall> they have become somewhat intertwined it seems. If we say yes to mojo, then the refactor is needed according to ollie
15:06:54 <tcohen> can we have a simpler integration of the permissions layer into your Mojo implementation, or you are stuck about it? have no idea how to do it? need other opinions?
15:07:29 <tcohen> i ask all this because i haven't had the chance to look at olli's work in depth
15:07:33 <Joubu> I think at the last meeting, Mojo didn't reach a consensus
15:08:06 <Joubu> tcohen: so nobody had a look at olli's work
15:08:18 <jajm> my feeling is that the rest api authentication worked without the rewrite when i first wrote it, but the check for permissions had to be done inside controllers instead of inside the swagger.json file
15:08:33 <Joubu> maybe because it's a +10k lines change :)
15:09:15 <tcohen> so, we would end up with a no-ideal implementation
15:09:33 <tajoli> I see only Olli's work are many new files
15:10:37 <jajm> i don't really know what are the benefits of declaring needed permission in swagger.json
15:11:11 <tcohen> ashimema: ?
15:11:32 <ashimema> got called away.. just cathcing back up
15:12:31 <tcohen> jajm is saying that in principle we could have the REST implementation in Mojo without a full Auth rewrite, the only issue is that we will end up hooking perm checks on the controllers instead of declaring it in swagger
15:13:18 <khall> and what limitations does that cause? Does that mean the permissions needed are not auto-documented?
15:13:47 <tcohen> besides the fact that some devs are quite unhappy with adopting Mojo and it will probably lead to more discussions, do u think that situation jajm depicts should be blocker for the implementation? is it something we could work on later?
15:14:08 <ashimema> hmm..
15:14:37 <ashimema> having 'everything' defined within the specification file is a 'nice to have' but I wouldn't say it's a must to start with.
15:15:20 <ashimema> by everything in that context I mean the permissions stuff in this case.
15:15:33 <ashimema> but I'm sure other stuff will come up in the future
15:15:37 <tcohen> my feeling is (besides de Mojo problem) that we have always tried to do an incremental work. with this 'external' endpoint, we have the chance to do it incrementally, reusing what we already have, and taking the time to make things better on a as-needed basis
15:15:42 <jajm> aside from that, i'm wondering if permissions in swagger.json will be sufficient. for example, what if we want to require 'borrowers' permission for /borrowers/XXXX only when XXXX is not me ?
15:16:50 <ashimema> jajm, that's a very viable use case.. and your right.. there's no clear way to define that logic in a swagger specification
15:17:45 <ashimema> the swagger plugin for mojo does treat auth simply as a these pages need authentication, these don't approach..
15:17:54 <ashimema> it's doesn't deal with roles as far as i'm aware
15:18:18 <ashimema> roles = authorization as aposed to authentication I suppose..
15:18:39 <ashimema> it's certainly a complex problem without a simple soution
15:19:16 <tcohen> jajm: is it possible that your implementation is reduced to using user authentication (CGISESSID) and check for the needed permissions on the controller so it is simpler to think of and test?
15:19:35 <ashimema> part of my issues with the 'external' api is that our 'internal' api is so all over the place
15:19:59 <tcohen> you mean we are probably inconsistent? :-D
15:20:02 <ashimema> pretty much all of our authen methods do eventually end up with a CGISESSID cookie..
15:20:08 <ashimema> so I think that would be a great way forward
15:22:18 <jajm> tcohen, it is certainly possible to check for CGISESSID cookie before the api key stuff, if this is what you mean
15:22:45 <ashimema> I'd kinda like to see an example of an area of our code that's written to take advantage of all the Mojo stuff.
15:22:56 <tcohen> what i mean is to take all but CGISESSID-based authentication out
15:23:33 <tcohen> and have the end-point require the same permissions patrons.pl requires (for example)
15:24:57 <tcohen> ashimema: i don't think we can find that, as the REST end-point would only benefit a UI integration using AJAX (like if we used angular)
15:25:42 <jajm> tcohen, it's also possible (even if i don't understand why we would remove apikeys authentification)
15:25:45 <tcohen> ashimema: you are asking why we think using a web framework like Mojo would benefit the project compared to just sticking to Koha::SErvice?
15:26:00 <t4nk493> Hello!, I got a question about hourly loans
15:26:03 <ashimema> That's sorta my point.. the biggest use case for a nice restful api, is for a angualr like ui as the consumer..
15:26:36 <ashimema> thus, I think whoever is doing the api work needs to prove they've 'got it' from the consumers point of view too..
15:26:39 <ashimema> dogfooding the api
15:26:40 <t4nk493> Koha takes care about the close time of the library to issue in hours?
15:27:15 <ashimema> I have nothing against Mojo.. in fact I love it.
15:27:24 <khall> ashimema: you are correct. That's is/was the plan with the ajax based circ pianohacker has written. Once we've got our RESTul services, he'll be rewriting it to use them
15:27:43 <ashimema> but I'm not entirely sure how it intergrates into koha as is..
15:27:44 <t4nk493> if the library close at 19:00 and you checkout at 17:00 for 3 hours, Koha must force this checkout to 19:00 instead of 20:00 ...
15:27:56 <ashimema> khall.. I think circ is too big fro such an example..
15:28:11 <ashimema> I was more thinking a tiny area of functionality..
15:28:14 <khall> ashimema: as a proof of concept, yes, way too big
15:28:22 <ashimema> say 'Your patron lists' under the tools area?
15:28:29 <ashimema> that's tiny, well defined.
15:28:52 <ashimema> hopefulyl wouldn't take too much to create the api routes for etc.
15:28:57 <tcohen> https://github.com/tomascohen/koha/commit/812a53f41681dc01833915240079d259f24d4694
15:29:17 <ashimema> that way we can see how people are suggesting integrating te mojo stuff into the existing koha stuff..
15:29:22 <khall> ashimema:I think you are asking for a proof of concept patch that would actually use the mojo based rest api. is that correct?
15:29:31 <khall> use it within Koha that is
15:29:45 <ashimema> yeah..
15:30:02 <tcohen> chicken-egg situation
15:30:18 <ashimema> that way one can look at it, prove it's all working.. authentication, api routes, etc etc.
15:30:35 <jajm> ashimema, i don't know angular, but can't we make it use the apikey mechanism ?
15:30:41 <khall> ok. We could go about this by replacing something in svc with a mojo equivalent then modify the code calling the svc script to use mojo instead
15:30:42 <ashimema> I dunno.. it's all conjecture at this point fomr me as I've not got the time to do anything much on koha :(
15:31:22 <ashimema> I dont' entirely understand your api key mechanism..
15:31:39 <ashimema> feels like re-inventing the wheel somewhat (i've done that plenty of times.. usually not a good idea)..
15:31:46 <tcohen> jajm: angular is running on the browser, and reuses the session cookie
15:32:29 <ashimema> jajm.. can you sum up what your apikey stuff achieves?
15:32:33 <ashimema> what's it's use case?
15:32:38 <tcohen> the api-key mechanism is similar to google's api key mechanism, but i think it only introduces noise to this
15:33:01 <tcohen> that's why i propose to leave that out of the discussion
15:33:32 <tcohen> it *might* be useful, but the use cases we should be considering are using the REST endpoints from the Koha UI
15:34:26 <ashimema> agree with tcohen.
15:34:48 <jajm> ashimema, it's a bit hard to summarize it, but it's designed to be secure and is based on this page (http://blog.ineat-conseil.fr/2013/01/restful-authentication/ - 7th point - in french, sorry)
15:34:55 <ashimema> using cgisessions for me is a first case
15:35:13 <khall> agreed
15:35:34 <khall> cgisessions will still work with external services, it's just not as simple
15:37:22 <jajm> if we agree to use cookie based authentication, the whole point of using apikeys mechanism (security) is lost imo
15:38:45 <tcohen> jajm: i'm not sure about that, but certaintly the session cookie use case is really important at this point
15:39:14 <tcohen> and given the fact that having the permissions layer defined on the swagger configuration is not that obvious
15:39:21 <ashimema> there's two disperate use cases here..
15:39:44 <tcohen> i think we could have a functional POC to play with, without rewriting Koha to have a RESTful endpoint
15:40:06 <ashimema> tcohen, khall adn I are thinking about the internal uses (i.e the Koha Client), jajm is thinking of the external uses ( i.e joomla, druple whatever as the client)
15:40:46 <ashimema> both use cases are definitely important.
15:40:55 <tcohen> ashimema: exactly, and that is correct, but we could do that on a separate bug
15:42:04 <ashimema> jajm, that page bascialyl describe OAuth.. if we want to go that route.. we should use actual OAuth
15:42:05 <ashimema> ;)
15:42:34 <ashimema> that's a different conversation though.. as tcohen says
15:43:45 <marcelr> sorry, have to go
15:46:44 <fridolin> see u
15:47:04 <khall> I agree with ashimema both internal and external use cases a equally important and necessary
15:47:24 <khall> I know Ebsco wants to do neat stuff with Koha once we have an API in place
15:47:41 <ashimema> I'm still struggling with the apikey stuff..
15:47:50 <ashimema> trying to read the code quickly..
15:47:59 <ashimema> it looks to me like your giving a key to each user?
15:48:24 <jajm> ashimema, yes
15:48:47 <ashimema> that's madness.. that's just like giving them yet another password
15:49:12 <ashimema> the apikey notion is all about allowing app to app communication..
15:49:31 <ashimema> So.. you have an apikey per application that wants to consume your api..
15:50:02 <Joubu> I don't think so, 1 apikey per koha user
15:50:14 <ashimema> app x wants permission to access app y, app y generates a key and gives it to app x... app x then signs all requests to app y with their key (you've authenticated the APP)..
15:50:15 <Joubu> 1 user could use several apps
15:50:42 <jajm> ashimema, it's like another password... but a password that is not sent through network, it's only used to encrypt the request
15:50:55 <ashimema> app x want's to access user z's data in app y, user z has to allow app x said access by logging into app z and allowing it.
15:51:35 <ashimema> if user z wants to login to app x with their account from app y, then they just use their username and password..
15:51:51 <ashimema> preferably within the originating app.. nto the external one..
15:52:01 <ashimema> this is how github, google, facebook etc all work
15:52:38 <ashimema> I think your mistaking a password for an auth token here
15:52:42 <jajm> anyway... as a first step we could use only cookie based authentication, that will let us the time to rethink about api key authentication
15:52:55 <ashimema> sounds good to me..
15:53:01 <Joubu> yes please, a first step :)
15:53:12 <tcohen> jajm++
15:53:29 <khall> agreed!
15:53:34 <ashimema> I'd read up on OAuth and JWT jajm.. those are the technologies that are leading the pile for this sort of thing..
15:53:46 <ashimema> but using cookies for now is perfectly acceptable to me.
15:53:47 <ashimema> in app.
15:54:04 <tcohen> jajm: i have only one concern with the patchset (once we limit the scope of the bug to cookie sessions)
15:54:08 <ashimema> I do have some plans to increase our cookie security a bit shuold we need to..
15:54:22 <ashimema> I'm not entirely sure if we're hmac'ing them or not at the moment..
15:54:27 <ashimema> or any of the other clever stuff..
15:54:40 <ashimema> jajm++
15:54:50 <Joubu> hmac'ing?
15:54:57 <ashimema> cookies aren't inherantly insecure.. it's how most people use them that is.
15:55:16 <tcohen> jajm: if you take a look at the plack integration i've made, you will notice I added (commented out) a /api route on the apache configuration for packages
15:55:24 <Joubu> k got it
15:55:48 <ashimema> adding timestamps and bits Joubu
15:56:05 <ashimema> that page jajm linked to (in french) will probably explain them better than me.
15:56:16 <tcohen> we should really think of a way to make running this easier
15:56:22 <ashimema> to note though.. mojo session cookies are hmac'd out of the box ;)
15:56:33 <tcohen> so we could use that route or change it
15:57:02 <jajm> tcohen, what is your concern exactly ?
15:57:29 <tcohen> if it is possible to integrate your work into the packages configuration for easier testing
15:58:04 <tcohen> olli added several configuration files, etc
15:58:20 <tcohen> it has got a bit messy
15:58:27 <tcohen> requiring a domain name to run it
15:58:32 <jajm> tcohen, you're talking about http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13791 ?
15:58:33 <huginn> 04Bug 13791: enhancement, P5 - low, ---, tomascohen, Pushed to Master , Plack - Out of the box support on packages
15:58:34 <tcohen> api.<your koah>
15:58:44 <tcohen> yeap
15:59:09 <Joubu> so, what's the next step?
15:59:48 <tcohen> to me, the next step is that we clean the bug up
16:00:15 <tcohen> and reduce the patchset to only session cookie authentication
16:00:31 <tcohen> i volunteer to help on writing the patches to integrate this with the packages
16:02:14 <Joubu> Should we take a decision for Olli's patchs?
16:02:32 <Joubu> not now, but another meeting dedicated to this subject?
16:02:42 <jajm> tcohen, patch 1.1 of http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13799 changes just that: it allows to access api through http://opac/v1/... or http://intranet/v1/...
16:02:43 <huginn> 04Bug 13799: new feature, P5 - low, ---, julian.maurice, Needs Signoff , Add base for building RESTful API
16:02:59 <tcohen> first things first
16:03:17 <tcohen> jajm: do u think you can have the time to work on the changes that have been mentioned?
16:03:53 <tcohen> i mean, you or biblibre (who were in charge of this work)
16:04:04 <jajm> tcohen, maybe we should discuss that with Olli first, don't you think ?
16:04:36 <bag> morning
16:04:42 <tcohen> jajm: I think we can all agree that there is a consensus that the full Auth rewrite is not mandatory at this point
16:05:04 <tcohen> it is a good road to go through, but not blocker to have this move on
16:05:08 <bag> thanks for chatting about this (got here as fast as I could)
16:06:11 <tcohen> but i think it is ok to include Olli on this session cookie implementation if you feel like
16:06:40 <jajm> ok
16:06:49 <tcohen> jajm: do u think you can have the time to work on the changes that have been mentioned? probably with Olli's help?
16:07:02 * tcohen wants t owrite an #action right now :-D
16:08:38 <jajm> tcohen, you can write an #action ;)
16:09:15 <jajm> i can work on that soon
16:09:18 <tcohen> #action Julian/Biblibre will refactor his REST API implementation so it does session cookie authentication, and API-key mechanism implementation/discussion will be dealt with on a separate bug
16:10:03 <tcohen> #action Tomas will help if needed on integrating it to the packages and kohadevbox so testing it is easier for anyone
16:10:22 <tcohen> #action Jonathan will bring the belgian beer we all miss
16:10:37 <bag> YAY!
16:10:37 <jajm> \o/
16:10:48 <tcohen> Joubu: regarding the Auth rewrite
16:11:11 <tcohen> I think that work looks good so far, and it should probably be discussed on the next dev meeting
16:11:13 <ashimema> got called away to fix a server.. back now.
16:11:19 <ashimema> yeay.. actions
16:11:24 <tcohen> if Olli is available
16:11:46 <tcohen> #action Tomas will ask Olli when he can be available to attend a dev meeting to discuss his Auth rewrite
16:12:08 <tcohen> am i missing something?
16:12:17 <tcohen> ah, yeah
16:12:31 <tcohen> Kyle volunteered to write a POC using the REST API
16:12:34 <tcohen> right?
16:12:35 <tcohen> :-D
16:12:54 <khall> yes!
16:13:07 <khall> I'll give it a shot at least
16:13:50 <tcohen> #action Kyle and pianohacker will be looking into this rewrite of the REST api to base their AJAX circulation work on it
16:13:57 <ashimema> use a nice tiny page pretty please khall ;)
16:14:18 <tcohen> ashimema: we were thinking of rewriting the framework editing pages :-P
16:14:25 <ashimema> I'm shying away from reading scary big re-writes of massive modules at the moment..
16:14:28 <ashimema> haha
16:15:00 <tcohen> anyone has something else to add to this?
16:15:27 <tcohen> i feel we need to move on as this got pretty lenghty
16:16:03 <tcohen> ok, moving on
16:16:05 <tcohen> #topic 'Big stuff we are working on'
16:16:37 <tcohen> anyone?
16:16:38 <wahanui> i heard anyone was free to organize one at any time :-)
16:16:44 * ashimema has to scarper.. i'm on tea cooking duty this evening and the girls are screaming hungry
16:16:45 <khall> I've been working on a document delivery / article request feature. I know cait's ears perked up when I filed the bug ; )
16:16:55 <ashimema> awesome khall
16:16:57 <ashimema> khall++
16:17:02 <tcohen> khall++
16:17:21 <tcohen> #info Kyle has been working on a document delivery / article request feature
16:17:25 <tcohen> bug number?
16:18:00 <khall> will find
16:18:29 <tcohen> someone else?
16:18:30 <khall> bug 14610
16:18:31 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14610 enhancement, P5 - low, ---, gmcharlt, NEW , Add ability to place document delivery / article requests in Koha
16:18:56 <tcohen> #link http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14610
16:18:57 <huginn> 04Bug 14610: enhancement, P5 - low, ---, gmcharlt, NEW , Add ability to place document delivery / article requests in Koha
16:20:16 <tcohen> I have started working on using some of the prior work from jcamins to better abstract search results and for moving around records. One of the goals is to make them carry some data on their own
16:20:26 <tcohen> like metadata schema, serialization format
16:21:01 <tcohen> ideally, we could get JSON, USMARC, XML, etc and have the code know what to do with each of them
16:21:16 <tcohen> that's what I've been thinking about
16:21:52 <tcohen> the ES implementation will translate things into MARC to reuse the current business logic/presentation logic
16:22:23 <tcohen> but at some point we should just use Koha::RecordProcessor (with Koha::Filter::*) to handle just
16:22:30 <tcohen> Koha::MetadataRecord objects
16:23:18 <tcohen> that way, if we want to support a different serialization format, we just need to subclass Koha::Filter, to handle our serialization format, and unit tests would be already written
16:23:37 <jajm> is there a bug number ?
16:23:58 <tcohen> my preliminary work so far:  bug 14645
16:23:59 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14645 enhancement, P5 - low, ---, tomascohen, ASSIGNED , Koha::RecordProcessor should deal with Koha::MetadataRecord objects
16:24:23 <tcohen> and bug 14639
16:24:24 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14639 enhancement, P5 - low, ---, tomascohen, Signed Off , Extend Koha::MetadataRecord to handle serialization format
16:25:07 <tcohen> we should then make ES / Zebra code return Koha::MetadataRecord objects
16:25:36 <tcohen> probably wrapped inside Koha::Search::Results or something similar
16:25:54 <tcohen> anyway, i just mention it for anyone interested to know
16:26:58 <tcohen> once i have something more interesting i will show up, probabluy robin will have something to add/discuss about this
16:27:02 <tcohen> ok
16:28:30 <tcohen> #info Tomas is starting to work on some better abstraction using Koha::MetadataRecord for easier handling of different serialization formats and better code modularity (i.e. rewriting C4::Search, specially the code that deals with filtering record data)
16:28:41 <tcohen> #link http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14645
16:28:41 <huginn> 04Bug 14645: enhancement, P5 - low, ---, tomascohen, ASSIGNED , Koha::RecordProcessor should deal with Koha::MetadataRecord objects
16:28:48 <tcohen> #link http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14639
16:28:49 <huginn> 04Bug 14639: enhancement, P5 - low, ---, tomascohen, Signed Off , Extend Koha::MetadataRecord to handle serialization format
16:28:53 <tcohen> someone else?
16:29:10 <tcohen> #topic GBSD - Reminder, things that need to be done
16:30:01 <tcohen> #info Remember we have a Global Bug Squashing Day (GBSD) planned for September 3 2015
16:30:05 <tcohen> don't miss it
16:30:42 <tcohen> #info if you have something you think might be interesting for that day, please check here http://wiki.koha-community.org/wiki/2015-09-03_Global_bug_squashing_day
16:31:00 <tcohen> i really have to leave, so if no one else has something to add
16:31:17 <tcohen> #topic Set time of next meeting
16:31:33 <tcohen> #action Tomas will post on koha-devel with a proposal for the next meeting
16:31:44 <tcohen> and that's it
16:31:54 <tcohen> thanks everyone
16:31:59 <tcohen> jajm++
16:32:03 <jajm> thanks tcohen
16:32:13 <tcohen> #endmeeting