19:01:03 #startmeeting Development IRC meeting 28 February 2018 19:01:03 Meeting started Wed Feb 28 19:01:03 2018 UTC. The chair is tcohen. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:03 The meeting name has been set to 'development_irc_meeting_28_february_2018' 19:01:10 *sorry* 19:01:14 #link https://wiki.koha-community.org/wiki/Development_IRC_meeting_28_February_2018 19:01:29 notarock: np! 19:01:40 #topic Introductions 19:01:56 #info Jonathan Druart 19:01:59 #info Lee Jamison, Marywood University 19:02:10 #info Tomas Cohen Arazi, Theke Solutions 19:02:20 #info Josef Moravec, Czech Republic 19:02:27 #info Owen Leonard, Athens County Public Libraries, USA 19:02:59 we'll wait a couple more minutes 19:03:41 ok, 1.05 minutes 19:03:43 #topic Announcements 19:03:52 Any announcements? 19:04:01 yes 19:04:20 #info brendan gallagher bywater 19:04:30 I will be afk most of March, kidclamp has push permissions as RM assistant and will take care of the mess I left behind me 19:04:40 * kidclamp is luck 19:04:43 y 19:04:56 Joubu: make sure you push everything, kidclamp will fix it 19:05:01 I will answer to emails if there is something need (contact on my private email, not @bugs.k-c.org if urgent) 19:05:12 something needed* 19:05:30 I pushed quite lot of things in the last two weeks 19:05:41 #info Nick Clemens, ByWater Solutions 19:05:44 #info Jonathan will be mostly AFK during March, Nick will be in charge as RM assistant 19:05:49 in anothe rmeeting, half an eye here though 19:06:14 + trivial bypassing SO + QA 19:06:15 I'd like to avoid such situation (bypassing steps), but the SO queue is too high 19:06:20 kidclamp: you're late, you've just been volunteered to be the RM during March 19:06:41 so, no worries, keep your eyes on the other meeting 19:06:45 * kidclamp *thumbs up* 19:06:53 Keep in mind that we are going to feature freeze quite quickly (in less than 2 months), so if we want to see things pushed, it's *now* 19:07:56 I think that's all (apart of things I have already said in emails or "what's on") 19:08:15 Joubu++ # deserved vacation 19:08:39 any other announcement? anyone? 19:08:51 nothing comes to mind 19:09:02 oleonard? bag? 19:09:16 ok, moving on 19:09:19 nope 19:09:27 #topic Update from the Release manager (18.05) 19:09:28 * oleonard eagerly looking forward to his SASS patch to make it in 19:09:44 oleonard: what's missing? 19:09:48 what I told previously :) 19:10:19 hackfest in france starts 12th of march! hopefully lots of sign-offs that week 19:10:22 One follow-up needs signoff on Bug 19474 19:10:22 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19474 enhancement, P5 - low, ---, oleonard, Needs Signoff , Convert staff client CSS to SCSS 19:11:53 #info Staff client CSS to SCSS patches are waiting for love and are important 19:12:23 #topic Update from the Release Maintainers 19:12:24 Project Koha_Master_D8 build #395: SUCCESS in 36 min: https://jenkins.koha-community.org/job/Koha_Master_D8/395/ 19:12:33 jenkins: shh 19:12:33 tcohen you may not issue bot commands in this chat! 19:12:47 as well as the "Move template JavaScript to the footer" patches 19:13:10 Please don't be afraid of the UNIMARC ones. You don't need a UNIMARC system to test them. 19:13:13 rmaints? 19:13:24 no wahanui today 19:13:29 I am pushing as I can, trying to not get too far behind 19:13:43 next month's release will be on 25th due to hackfest and schedules 19:14:07 #info Nick is making sure 17.11.x is as close to master as possible 19:14:40 #info 17.11.04 will be delayed a couple days due to Marseille's THE hackfest 19:15:06 #topic UPdates from the QA team 19:15:35 ZE hackest (with a French accent please) 19:15:47 hehe 19:16:54 ok 19:17:25 #info Katrin has been pushing the QA team members, if you are looking for QA attention, contact her 19:18:05 #topic REST api 19:18:26 the crazy graph needs attention - https://bugs.koha-community.org/bugzilla3/showdependencygraph.cgi?id=15449 19:19:09 right 19:20:22 #info Signoff-ers and QA-ers, please look at this crazy graph https://bugs.koha-community.org/bugzilla3/showdependencygraph.cgi?id=15449 19:21:13 About REST api, the first item was a question I had, because I'm not a native speaker and terminology dragged me down 19:21:28 I asked privately to some of you 19:22:03 What we call baskets is usually called 'orders' in specialized systems, and then orders are actually 'orderlines' 19:22:32 I wrote that line in the meeting's agenda because we could have the chance to fix this if it was worth, on the API side 19:22:42 but I don't think it is worth for v1 19:23:05 comments? 19:24:11 I honestly have done hardly anything with the API so I'm unsure if I could be of help lol 19:24:18 we do not have api for this now, so probably worth it? 19:24:35 if it's not too complicated ;) 19:25:23 I have no strong opinion on how important this is 19:25:39 getting other systems to want to use the API is important 19:26:02 but it was obvious when looking at other sample APIs for writing the spec for the orders endpoint, that we were different than any other system 19:26:05 so I would say that if most everywhere does “orders” as baskets - we should do that for the API 19:26:41 and so basket_groups could become order_groups 19:26:46 yes 19:27:01 can any native speaker volunteer to propose this on an email to koha-devel? 19:27:16 I will 19:27:18 at least someone familiar with that management terminology 19:27:19 thanks! 19:27:26 I am not sure the acquisition module is ready for the REST API 19:27:47 either is the Auth system ;) 19:27:49 #actions Brendan will explain in koha-devel the question about terminology for orders/baskets 19:27:53 As I told it on 1 comment, Koha::REST should only use Koha::Object(s)-based object 19:28:04 to have only 1 way to write things 19:28:34 just my thoughts 19:29:04 I think that would be ideal, but here we're mostly talking about the spec, right? 19:29:07 that is ideal yes - but is that practical to have to wait for the rewrite of Object(s)-based acq 19:29:22 it is as discussing what would the ideal DB structure be 19:29:47 we can design a good API spec in terms of good practices 19:30:04 and then see how it can fit our codebase, and plan for refactorings if needed 19:31:47 #info Jonathan mentions (again) he thinks the REST api development should be done on top of Koha::Object(s)-based classes 19:32:05 more code will use C4 and more difficult it will be to move it 19:32:21 anyway, it's not the discussion here 19:32:54 it is part of a broader discussion/problem we need to deal with 19:33:14 probably on another place 19:33:30 maybe a round table during the hackfest 19:33:53 anyway. I'm supposed to move the meeting forward 19:34:36 the next subject is a proposal to change the /illrequests endpoint spec 19:34:39 * oleonard doesn't remember any round tables 19:35:00 *rectangular tables*, sorry 19:35:16 josef_moravec: you want to talk about your proposal? 19:35:48 Just a note 19:36:15 i propose to change "updated" to "timestamp" 19:36:29 because of consistency of other endpoints 19:37:13 josef_moravec: I agree with most of the attribute name changes, but there's something deeper to think about ill_requests 19:37:28 because each backend is supposed to support its own attribute sets 19:37:35 yes 19:37:46 and so, we face two problems 19:38:09 - We still need to make backends plugable (like with plugins) 19:38:24 - Probably have the plugins inject new routes 19:38:35 for example /ill_requests/free_form/ 19:38:37 etc 19:39:21 understand, but it means somehow enhance our plugin system 19:39:41 endeed 19:39:52 so, for now, it is a blocker to this endpoint 19:40:03 either path we pick, I think your spec should be constrained to just listing I think 19:40:11 or yes, blocked for now 19:41:00 this should be covered in proposals, so postpone voting to next meeting? 19:41:07 #info Josef agreed some work on the backend-side is needed for actions on the illrequests endpoints (besides LIST) 19:41:09 yes 19:41:24 I'll enhance the proposal 19:41:40 Next is the orders endpoint 19:41:47 thanks tcohen 19:42:48 I didn't complete the PATCH spec matching all possible flows orders have because I had to go deep in the code to find all required attributes for each action 19:43:28 but basically, I propose having /acq/orders/order_id 19:43:40 for all CRUD 19:44:00 and then use PATCH for specific actions like 'receive' an order(line) 19:44:11 or 'cancel', etc 19:44:32 another option is to treat those actions as resources 19:44:58 like POST /acq/orders/123/receipts { date_received: blah } 19:45:28 our DB design doesn't allow to do this in a natural way 19:45:47 because partial receipts create separate 'orders' 19:46:01 (that happen to be descendants of the original one) 19:46:21 so we don't really have a separate table with a 1-* relationship 19:46:27 as /receipts would imply 19:46:39 we could emulate it on the API, but migt get troublesome 19:47:50 for terminology (attributes) I contacted some of you (including Katrin, etc) 19:48:47 ok, if there aren't any opinions… 19:48:53 I am for using PATCH, does make more sense to mee from view of using API 19:49:36 from a consumer POV, the only deficiency I find (in the overall DB design, which permeates to the API) 19:49:50 is that if we PATCH to receive an order (partially) 19:50:02 the result is that a new order is created "behind the scenes" 19:50:23 so, for rendering the list of orders (standing or not) 19:50:37 we would need to GET /../orders again 19:50:44 to refresh the list 19:51:04 besides the baskets/orderlines renaming 19:51:12 but that is just for receiving, true? 19:51:16 true 19:52:20 we could emulate a resource-oriented approach 19:52:32 by detecting 'descendants' orders 19:52:45 but it will get messy, for sure 19:53:23 yes it will, but that's 'our' problem, this is iplementation detail, and should not be shown in the API 19:53:36 true 19:53:56 but we don't want messy code at all, that's true too 19:54:19 could we vote the general spec and I can focus on this details for a proposal on this specific actions against orders? 19:54:40 I don't really need a vote, but a general agreement on terminology and such 19:54:47 we could, this is for another disscusion 19:55:10 +1 from me 19:55:15 anyone has a case against this spec? 19:56:30 wher eis the /receipts? 19:56:33 where is the /receipts? 19:56:50 this proposal doesn't include it 19:56:54 k 19:57:00 it actually includes the PATCH solution 19:57:18 I can work on putting the /receipts proposal in words 19:57:28 "parent_order_id" should not be exposed, right? 19:57:33 exactly 19:58:07 Ah, it is in the spec :-D 19:58:35 tax_value_on_ordering and tax_value_on_receiving neither I guess 19:58:36 it shouldn't be exposed, if we create the /receipts one 19:58:41 with PATCH, we need it 19:58:43 you will have to calculate them yourself 19:58:53 * oleonard ducks out 19:59:29 Joubu: I'm not sure about those two, they cna be changed on receiving, from the UI 19:59:39 I am not sure where we are going 19:59:45 but you can go :) 20:00:39 ok 20:01:15 if we have any ideas about who is going to use this API, we should contact them first 20:01:26 and talk with them to understand what they want/need 20:01:52 unless you know already 20:02:02 #actions Tomas will enhance the /orders endpoint spec with some missing possible solutions for the 'receive' and 'cancel' use cases, there's a general consensus on attribute names 20:02:23 Joubu: I've been thinking on the use case: 'rewrite the orders handling UI' 20:02:38 so, looking at things that are handshaked on each step from the UI 20:02:46 and how this would fit in a RESTful api 20:03:05 and then, I've worked on GOBI integration (an external acq system) 20:03:15 and have had talks with people integrating Coral 20:03:26 both of them really need a very simplified API 20:03:40 because they don't need to care about creating a basket, etc 20:03:56 they usually send orderlines along with a MARC record 20:04:05 and expect things to be processed magically 20:04:06 so 20:04:17 which is better for us then 20:04:19 * cait waves 20:04:30 I'm thinking of a set of endpoints that can be used in both 'the complex' and 'the simple' way 20:04:32 we do not need to create endpoints for baskets, invoices, etc. 20:04:50 Joubu: it depends 20:05:19 becuase orders (baskets) are needed inside Koha to be able to display them 20:05:47 I mean, we could strip everything out, but that's a major thing on the codebase 20:05:49 he 20:05:55 * LeeJ waves to cait 20:06:07 sorry for missing most of the meeting 20:06:18 the idea is t do it as simple as possible, keeping in mind we would use it also for re-doing th UI 20:06:29 anyway 20:06:54 I'm fine to know there's no strong opinion against the chosen attribute names 20:07:04 we have existing endpoints but there are not used from our UI 20:07:10 so I doubt it's a good argument 20:07:18 details will be polished and proposed for next dev meeting 20:07:25 s/there/they #erk 20:07:34 I have a clear request to speed up orders management 20:07:41 that would benefit from such endpoints 20:08:05 ok, next one is patron password change endpoint 20:08:22 but I need to pick Manuel 20:08:33 #chair cait 20:08:33 Current chairs: cait tcohen 20:10:02 would it make sense to require the old password for use in systems like vufind? 20:10:50 who's around to talk about the REST api? 20:10:58 old password is not required in proposal 20:11:02 ok 20:11:59 old password is optional, on the header (not part of the password object) 20:12:13 and only useful for unprivileged users changing their own passowrd 20:12:15 not much to talk about here - in terms of terminology 20:12:23 :) 20:12:26 but VuFind could handle it 20:13:09 https://vufind.org/wiki/development:plugins:ils_drivers#changepassword 20:15:39 ? 20:16:25 everyone reading? :) 20:16:38 I am 20:17:07 so, are we going to vote? 20:18:31 let's go :-) 20:18:56 which one? 20:19:07 password change 20:19:45 +1 20:20:00 +1 20:20:14 +1 20:20:44 * Joubu abstains 20:23:37 ok, i think i missed that tcohen left 20:23:39 making me chair 20:23:47 #agreed RFC for password change is accepted 20:23:53 are there others we shoudl vote on? 20:24:25 josef_moravec: ? 20:24:37 i have no idea where in the agenda we are, help :) 20:24:52 set a time for next meeting sounds good 20:25:01 Joubu++ 20:25:19 ok 20:25:21 thx :) 20:25:26 #topic Set time of next meeting 20:25:26 cait: we discussed the previous points before 20:25:49 wednesday in 2 weeks? 20:25:59 yep 20:26:02 march 14 20:26:06 sounds good 20:26:14 which time? 20:26:39 14 20:26:46 #info Next meeting: 14 March 2018, 14 UTC 20:26:53 thx all for attending :) 20:27:00 #endmeeting