14:14:18 #startmeeting Development IRC meeting 26 August 2015 - part 1 14:14:18 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:14:18 The meeting name has been set to 'development_irc_meeting_26_august_2015___part_1' 14:14:25 #topic Introductions 14:14:25 #info wahanui, a bot that has become sentient 14:14:33 please introduce yourself with #info 14:14:42 #info Tomas Cohen Arazi, Theke Solutions 14:14:46 #info Jonathan Druart, UK 14:14:57 #info Marcel 14:14:58 #info Julian Maurice, BibLibre 14:15:16 #info Nicole Engard, ByWater Solutions 14:15:54 will wait a couple more minutes 14:15:59 for others to join 14:16:18 New commit(s) kohagit: Bug 11190: sitemap.pl -- Generate a Catalog sitemap / Bug 14557: Add holds count to holds tab / Bug 14557: Clean up biblio-view-menu.inc / Bug 14714: Add tab-completion to koha-mysql command / Bug 14361: koha-restart-zebra fails and probably breaks upgrade / Bug 12632: (regression tests) Unit Tests / Bug 12632: Hold limits ignored for record level holds with item level itemtypes / Bug 7143: Add Benjamin Rokseth to the projects history file and about page / Bug 7143: spaces in history.txt instead of tabs break display on website / Bug 9809: DBRev 3.21.00.19 / Bug 9809: Remove one more occurrence of reserveconstraints / Bug 9809: Fix pod errors / Bug 9809: [QA Follow-up] Still found some remains / Bug 9809: [QA Follow-up] Remove constrainttype from 14464 tests / Bug 9809: [QA Follow-up] Remove an erroneous call to GetReserveFee / Bug 9809: [QA Follow-up] Remove warnings from Hold.pm / Bug 9809: Update AddReserve prototype to remove constraint parameter / Bug 9809: Remove reserveconstraints references from C4::Reserves / Bug 9809: Update unit tests / Bug 9809: Remove DBIC module for reserveconstraints 14:16:35 huginn: shh, meeting 14:16:35 tcohen: downloading the Perl source 14:16:42 #info Zeno Tajoli, Cineca, Italy 14:16:49 #info mirko tietgen, berlin, germany 14:18:22 ok, i think that's all 14:18:32 khall_dnd: ? 14:18:47 ashimema? 14:18:48 rumour has it ashimema is on qa now .) 14:18:51 #info Kyle M Hall, ByWater Solutions 14:18:57 dnd is for dungeon and dragon, isn't it? 14:19:04 yeah, he's distracted 14:19:12 no longer 14:19:13 ok, moving on then 14:19:15 ; ) 14:19:20 #topic RM 3.22 comments 14:19:28 please RM, speak 14:19:37 not here? ok, moving on 14:20:24 #info some important sutff has been pushed recently, notably plack integration for packages and the sitemap building tool contributed by Tamil 14:21:05 #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 #action the RM will send a pull request for kohadevbox to be adapted to this new scripts 14:23:18 #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 is there some rule for using Koha::Logger? 14:23:41 please ask here on IRC for help if you have doubts on how to use it 14:23:46 Koha::Logger: it would be great to have a coding guideline about how to use it 14:23:49 yes 14:23:56 yes, I agree 100% 14:24:18 khall: you wrote a piece of text on the wiki on how to use it, right? 14:24:44 if khall writes that rule, that would be great :) 14:24:45 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 I think I've only done a wiki page for Koha::Object 14:25:15 see comments on http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14597#c6 14:25:16 04Bug 14597: major, P5 - low, ---, kyle, Signed Off , Reverting a batch where a record overlaid is now deleted record will fail 14:25:35 also an article on koha newletter ? 14:26:08 good idea tajoli 14:27:00 khall: would you write something we could vote on a next dev meeting? (sooner than this one) 14:27:11 absolutely! 14:27:34 #action Kyle will write a proposal for adding the use of Koha::Logger to the coding guidelines 14:27:51 questions? 14:27:51 questions are good :) 14:27:57 I expect questions on plack 14:28:16 we really need testing 14:29:10 is anyone using kohadevbox for testing here? 14:29:23 not yet, will do soon 14:29:46 For test I use dev install 14:30:22 maybe we could do some tutorial during the next GBSD 14:31:12 ok, i'll move faster so we get to the main topic 14:31:48 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 tcohen++ 14:32:21 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 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 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 this is a personal comment, but i want you to know that 14:34:23 it is a lot of work and too little fellows around 14:34:34 that's why i've been writing tab-completion patches and such 14:34:43 to stay focused on something fun 14:34:44 heh 14:34:45 ok 14:34:56 fun++ 14:35:00 I confirm that in Italy August is vacation month 14:35:17 as usual, let me know anything that is bothering or worrying you. better earlier than late 14:35:46 any other comments on my comments? 14:36:17 #topic RESTful API Implementation 14:36:34 work on this topic is sort of stuck right now 14:36:57 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 from the very beggining, the use of a web framework like Mojolicious has been subject of some criticism 14:38:04 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 while I am in favour of adopting Mojolicious 14:38:31 so, i support that implementation basis 14:39:16 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 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 we got to a halt situation 14:41:03 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 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 so.. apologies for little to no comments 14:41:51 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 khall: exactly, that's why this was raised in the previous REST meeting 14:42:52 does someone have looked at Olli's work ? i didn't have time to do so yet 14:43:36 is there a possibility that we integrate the current permissions checking code into the code jajm wrote with Mojo? 14:43:41 not in detail jajm.. it's a big piece 14:43:45 I've seen it and it look very nice 14:43:50 Olli work on Auth is based on many add on Koha:: 14:44:05 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 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 See graph of dependeces from this bug: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13995 14:45:42 04Bug 13995: enhancement, P5 - low, ---, olli-antti.kivilahti, Needs Signoff , Proper Exception handling 14:45:59 and be scary 14:46:43 I think it is a good work but there are many assuption on dependeces and evolution of Koha code into Koha:: 14:47:00 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 Many new pieces of code 14:47:21 The main problem, imo is that a lot of technical choices have been done, but without any consensus/discussion 14:47:44 if we continue in this direction, we'll never see something pushed for the next X years 14:47:49 (with X > 3) 14:48:00 Joubu: can u elaborate? (i assume you mean not only Mojo adoption) 14:48:08 exactlym this the problem "lot of technical choices have been done, but without any consensus/discussion" 14:48:13 I mean Olli's work 14:48:39 ok 14:48:48 The discussion has been done some months ago, and now we got several implementations 14:49:05 but nobody discuss and people does not work together 14:49:13 could we improvise a list of that decisions? 14:49:18 i can start: 14:49:26 - Exception handling 14:49:56 (i've seen code from Olli and Jonathan that is not exactly similar, but on the same direction) 14:50:03 (quite the same) 14:50:30 olli's introduces several (too many) files for each exception, Jonathan's puts all of them in a single file 14:50:58 but when people looks at olli's patch, they just get scared by how many new classes are introduced 14:51:04 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 khall++ 14:52:16 this point is certainly is less important :) 14:52:23 what is the bug number of Joubu's exceptions ? 14:52:23 the* 14:52:27 bug 14544 14:52:28 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 somewhere in one patch 14:52:44 thx 14:53:27 (http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=41958&action=edit) 14:54:12 http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=41958 14:54:18 oops 14:54:48 'description => "poeut"' 14:54:55 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 yes, agreed, there is no decision or discussion to get/have on this subject 14:55:52 i think we should have Koha::Exceptions for general ones, and the Koha::Exceptions:: on a as-needed basis 14:56:07 but do everyone agree on using exceptions ? 14:56:08 anyway 14:56:24 tcohen++ 14:56:41 khall: it was your idea :-D 14:56:52 : ) 14:57:07 jajm: I sure do. Does anyone *reject* the idea of using exceptions? 14:57:18 Joubu et al, can we try to create a list of implicit design decisions beside the use of Class::Exception? 14:57:46 tcohen: mine is on the list rewrite 14:57:50 bug 14:58:50 pm raises an exception, the pl sent it to the tt and the templates show a specific message 14:59:05 not sure we can have several ways to do :) 14:59:06 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 jajm: not everywhere, just at the right places 14:59:35 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 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 tcohen: yep 15:00:46 jajm: we already have if (!defined $something) { short_circuit_with_some_output_to_tt } else { move_on } everywhere 15:01:17 anyway, so we focus on the main subject 15:01:42 we found a design decision that needs to be discussed and consensus found before it can be pushed 15:02:12 the first thing is to reach a middle road approach so we at least look consistent 15:02:49 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 sounds good! 15:03:25 could we try to find another decisions that are implicitly made and should be discussed in the open? 15:03:53 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 I agree 15:04:13 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 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 grharry: later, we are having a meeting right now 15:04:44 tcohen: what about the auth refactoring? is that a discussion for now or later? 15:05:17 bug 7174 15:05:18 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 khall: i think we need to discuss if that rewrite would be mandatory for the REST work or not 15:05:40 ok, that makes sense 15:05:41 jajm: what's your feeling about it? 15:06:37 they have become somewhat intertwined it seems. If we say yes to mojo, then the refactor is needed according to ollie 15:06:54 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 i ask all this because i haven't had the chance to look at olli's work in depth 15:07:33 I think at the last meeting, Mojo didn't reach a consensus 15:08:06 tcohen: so nobody had a look at olli's work 15:08:18 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 maybe because it's a +10k lines change :) 15:09:15 so, we would end up with a no-ideal implementation 15:09:33 I see only Olli's work are many new files 15:10:37 i don't really know what are the benefits of declaring needed permission in swagger.json 15:11:11 ashimema: ? 15:11:32 got called away.. just cathcing back up 15:12:31 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 and what limitations does that cause? Does that mean the permissions needed are not auto-documented? 15:13:47 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 hmm.. 15:14:37 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 by everything in that context I mean the permissions stuff in this case. 15:15:33 but I'm sure other stuff will come up in the future 15:15:37 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 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 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 the swagger plugin for mojo does treat auth simply as a these pages need authentication, these don't approach.. 15:17:54 it's doesn't deal with roles as far as i'm aware 15:18:18 roles = authorization as aposed to authentication I suppose.. 15:18:39 it's certainly a complex problem without a simple soution 15:19:16 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 part of my issues with the 'external' api is that our 'internal' api is so all over the place 15:19:59 you mean we are probably inconsistent? :-D 15:20:02 pretty much all of our authen methods do eventually end up with a CGISESSID cookie.. 15:20:08 so I think that would be a great way forward 15:22:18 tcohen, it is certainly possible to check for CGISESSID cookie before the api key stuff, if this is what you mean 15:22:45 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 what i mean is to take all but CGISESSID-based authentication out 15:23:33 and have the end-point require the same permissions patrons.pl requires (for example) 15:24:57 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 tcohen, it's also possible (even if i don't understand why we would remove apikeys authentification) 15:25:45 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 Hello!, I got a question about hourly loans 15:26:03 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 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 dogfooding the api 15:26:40 Koha takes care about the close time of the library to issue in hours? 15:27:15 I have nothing against Mojo.. in fact I love it. 15:27:24 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 but I'm not entirely sure how it intergrates into koha as is.. 15:27:44 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 khall.. I think circ is too big fro such an example.. 15:28:11 I was more thinking a tiny area of functionality.. 15:28:14 ashimema: as a proof of concept, yes, way too big 15:28:22 say 'Your patron lists' under the tools area? 15:28:29 that's tiny, well defined. 15:28:52 hopefulyl wouldn't take too much to create the api routes for etc. 15:28:57 https://github.com/tomascohen/koha/commit/812a53f41681dc01833915240079d259f24d4694 15:29:17 that way we can see how people are suggesting integrating te mojo stuff into the existing koha stuff.. 15:29:22 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 use it within Koha that is 15:29:45 yeah.. 15:30:02 chicken-egg situation 15:30:18 that way one can look at it, prove it's all working.. authentication, api routes, etc etc. 15:30:35 ashimema, i don't know angular, but can't we make it use the apikey mechanism ? 15:30:41 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 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 I dont' entirely understand your api key mechanism.. 15:31:39 feels like re-inventing the wheel somewhat (i've done that plenty of times.. usually not a good idea).. 15:31:46 jajm: angular is running on the browser, and reuses the session cookie 15:32:29 jajm.. can you sum up what your apikey stuff achieves? 15:32:33 what's it's use case? 15:32:38 the api-key mechanism is similar to google's api key mechanism, but i think it only introduces noise to this 15:33:01 that's why i propose to leave that out of the discussion 15:33:32 it *might* be useful, but the use cases we should be considering are using the REST endpoints from the Koha UI 15:34:26 agree with tcohen. 15:34:48 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 using cgisessions for me is a first case 15:35:13 agreed 15:35:34 cgisessions will still work with external services, it's just not as simple 15:37:22 if we agree to use cookie based authentication, the whole point of using apikeys mechanism (security) is lost imo 15:38:45 jajm: i'm not sure about that, but certaintly the session cookie use case is really important at this point 15:39:14 and given the fact that having the permissions layer defined on the swagger configuration is not that obvious 15:39:21 there's two disperate use cases here.. 15:39:44 i think we could have a functional POC to play with, without rewriting Koha to have a RESTful endpoint 15:40:06 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 both use cases are definitely important. 15:40:55 ashimema: exactly, and that is correct, but we could do that on a separate bug 15:42:04 jajm, that page bascialyl describe OAuth.. if we want to go that route.. we should use actual OAuth 15:42:05 ;) 15:42:34 that's a different conversation though.. as tcohen says 15:43:45 sorry, have to go 15:46:44 see u 15:47:04 I agree with ashimema both internal and external use cases a equally important and necessary 15:47:24 I know Ebsco wants to do neat stuff with Koha once we have an API in place 15:47:41 I'm still struggling with the apikey stuff.. 15:47:50 trying to read the code quickly.. 15:47:59 it looks to me like your giving a key to each user? 15:48:24 ashimema, yes 15:48:47 that's madness.. that's just like giving them yet another password 15:49:12 the apikey notion is all about allowing app to app communication.. 15:49:31 So.. you have an apikey per application that wants to consume your api.. 15:50:02 I don't think so, 1 apikey per koha user 15:50:14 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 1 user could use several apps 15:50:42 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 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 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 preferably within the originating app.. nto the external one.. 15:52:01 this is how github, google, facebook etc all work 15:52:38 I think your mistaking a password for an auth token here 15:52:42 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 sounds good to me.. 15:53:01 yes please, a first step :) 15:53:12 jajm++ 15:53:29 agreed! 15:53:34 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 but using cookies for now is perfectly acceptable to me. 15:53:47 in app. 15:54:04 jajm: i have only one concern with the patchset (once we limit the scope of the bug to cookie sessions) 15:54:08 I do have some plans to increase our cookie security a bit shuold we need to.. 15:54:22 I'm not entirely sure if we're hmac'ing them or not at the moment.. 15:54:27 or any of the other clever stuff.. 15:54:40 jajm++ 15:54:50 hmac'ing? 15:54:57 cookies aren't inherantly insecure.. it's how most people use them that is. 15:55:16 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 k got it 15:55:48 adding timestamps and bits Joubu 15:56:05 that page jajm linked to (in french) will probably explain them better than me. 15:56:16 we should really think of a way to make running this easier 15:56:22 to note though.. mojo session cookies are hmac'd out of the box ;) 15:56:33 so we could use that route or change it 15:57:02 tcohen, what is your concern exactly ? 15:57:29 if it is possible to integrate your work into the packages configuration for easier testing 15:58:04 olli added several configuration files, etc 15:58:20 it has got a bit messy 15:58:27 requiring a domain name to run it 15:58:32 tcohen, you're talking about http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13791 ? 15:58:33 04Bug 13791: enhancement, P5 - low, ---, tomascohen, Pushed to Master , Plack - Out of the box support on packages 15:58:34 api. 15:58:44 yeap 15:59:09 so, what's the next step? 15:59:48 to me, the next step is that we clean the bug up 16:00:15 and reduce the patchset to only session cookie authentication 16:00:31 i volunteer to help on writing the patches to integrate this with the packages 16:02:14 Should we take a decision for Olli's patchs? 16:02:32 not now, but another meeting dedicated to this subject? 16:02:42 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 04Bug 13799: new feature, P5 - low, ---, julian.maurice, Needs Signoff , Add base for building RESTful API 16:02:59 first things first 16:03:17 jajm: do u think you can have the time to work on the changes that have been mentioned? 16:03:53 i mean, you or biblibre (who were in charge of this work) 16:04:04 tcohen, maybe we should discuss that with Olli first, don't you think ? 16:04:36 morning 16:04:42 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 it is a good road to go through, but not blocker to have this move on 16:05:08 thanks for chatting about this (got here as fast as I could) 16:06:11 but i think it is ok to include Olli on this session cookie implementation if you feel like 16:06:40 ok 16:06:49 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 tcohen, you can write an #action ;) 16:09:15 i can work on that soon 16:09:18 #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 #action Tomas will help if needed on integrating it to the packages and kohadevbox so testing it is easier for anyone 16:10:22 #action Jonathan will bring the belgian beer we all miss 16:10:37 YAY! 16:10:37 \o/ 16:10:48 Joubu: regarding the Auth rewrite 16:11:11 I think that work looks good so far, and it should probably be discussed on the next dev meeting 16:11:13 got called away to fix a server.. back now. 16:11:19 yeay.. actions 16:11:24 if Olli is available 16:11:46 #action Tomas will ask Olli when he can be available to attend a dev meeting to discuss his Auth rewrite 16:12:08 am i missing something? 16:12:17 ah, yeah 16:12:31 Kyle volunteered to write a POC using the REST API 16:12:34 right? 16:12:35 :-D 16:12:54 yes! 16:13:07 I'll give it a shot at least 16:13:50 #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 use a nice tiny page pretty please khall ;) 16:14:18 ashimema: we were thinking of rewriting the framework editing pages :-P 16:14:25 I'm shying away from reading scary big re-writes of massive modules at the moment.. 16:14:28 haha 16:15:00 anyone has something else to add to this? 16:15:27 i feel we need to move on as this got pretty lenghty 16:16:03 ok, moving on 16:16:05 #topic 'Big stuff we are working on' 16:16:37 anyone? 16:16:38 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 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 awesome khall 16:16:57 khall++ 16:17:02 khall++ 16:17:21 #info Kyle has been working on a document delivery / article request feature 16:17:25 bug number? 16:18:00 will find 16:18:29 someone else? 16:18:30 bug 14610 16:18:31 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 #link http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14610 16:18:57 04Bug 14610: enhancement, P5 - low, ---, gmcharlt, NEW , Add ability to place document delivery / article requests in Koha 16:20:16 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 like metadata schema, serialization format 16:21:01 ideally, we could get JSON, USMARC, XML, etc and have the code know what to do with each of them 16:21:16 that's what I've been thinking about 16:21:52 the ES implementation will translate things into MARC to reuse the current business logic/presentation logic 16:22:23 but at some point we should just use Koha::RecordProcessor (with Koha::Filter::*) to handle just 16:22:30 Koha::MetadataRecord objects 16:23:18 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