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