07:01:34 <cait> #startmeeting Development IRC meeting 24 August 2016
07:01:34 <huginn> Meeting started Wed Aug 24 07:01:34 2016 UTC.  The chair is cait. Information about MeetBot at http://wiki.debian.org/MeetBot.
07:01:34 <huginn> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
07:01:34 <huginn> The meeting name has been set to 'development_irc_meeting_24_august_2016'
07:01:37 <cait> #topic Introductions
07:01:37 <wahanui> #info wahanui, a bot that has become sentient
07:01:48 <cait> please introduce yourself with #info following wahanui's example
07:01:51 <cait> today's agenda is at
07:01:54 <cait> #link https://wiki.koha-community.org/wiki/Development_IRC_meeting_24_August_2016
07:02:08 <drojf> #info Mirko Tietgen, Berlin, Germany
07:02:15 <cait> #info Katrin Fischer, BSZ, Germany
07:02:22 <kidclamp> #info Nick Clemens, ByWater Solutions
07:02:36 <cait> hm
07:02:39 <cait> that's too easy
07:02:47 <Joubu> #info Jonathan Druart
07:03:06 <cait> Europe should be more awake :)
07:03:26 <cait> can we shake some more people awake?
07:03:53 <khall> #info Kyle M Hall, ByWater Solutions
07:04:11 <cait> hm ok
07:04:17 <cait> let's moveon, maybe we have some people oversleeping
07:04:29 <cait> #topic Announcements
07:04:37 <cait> any announcements?
07:05:15 <cait> maybe a quick question fromme
07:05:18 <cait> shoudl we try for another GBSD?
07:05:39 <Joubu> yes
07:05:41 <cait> i am not sure if people are still holidaying much everywhere
07:05:50 <cait> but mabe in 1-2 weeks
07:05:59 <drojf> don't have time for gbsd but in general, yes
07:06:01 <tcohen> #info Tomas Cohen Arazi
07:06:04 <kidclamp> yes
07:06:10 <cait> any preferences on a day?
07:06:14 <khall> can't hurt!
07:06:42 <cait> maybe friday 9th September?
07:06:43 <khall> maybe a friday?
07:06:50 <kidclamp> I like Fridays
07:06:57 <tcohen> friday
07:07:09 <cait> can we agree on the one in 2 weeks?
07:07:17 <cait> :)
07:07:30 <tcohen> +1
07:07:45 <kidclamp> +1
07:07:51 <drojf> i think there is a caffeine hackathon in berlin that day ;)
07:08:05 <reiveune> hello
07:08:05 <wahanui> hey, reiveune
07:08:06 <cait> #agreed Friday, 9 September will be GBSD = Global Bug Squashing Day
07:08:19 <cait> #action cait to update wiki and send info about GBSD to the mailing list
07:08:25 <cait> moving on?
07:08:51 <cait> #topic Review of coding guidelines
07:08:55 <cait> no suggestions have been made
07:09:03 <cait> is there something people want to discuss?
07:09:37 <cait> i will take the quiet as a clue to move on
07:09:38 <tcohen> I would like to mention
07:09:40 <cait> ah
07:09:46 <fridolin> hie
07:10:01 <tcohen> I've been looking at REST-related patches the last couple days
07:10:27 <tcohen> and while not finished, there will be need for coding guidelines for the swagger files
07:10:44 <cait> #info tcohen is working on the REST-related patches and suggests adding coding guidelines for the swagger files
07:10:50 <tcohen> maybe this should be discussed on another meeting of course
07:10:53 <cait> can you detail a bit?
07:10:58 <cait> like give an example?
07:11:22 <tcohen> i'm abit asleep still
07:11:49 <tcohen> the original swagger file was about to get bigger and bigger
07:11:50 <cait> ok, so maybe we shoud just keep it in mind and add to next meeting?
07:12:05 <khall> tcohen: that's ok, I think kidclamp and I are too ; )
07:12:15 <tcohen> and there are patches on the queue that propose splitting
07:12:22 <tcohen> the file into pieces
07:12:32 <tcohen> I like the schema they are proposing
07:12:44 <tcohen> but as there hasn't been much attention on them
07:12:51 <kidclamp> bug 15126
07:12:52 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15126 enhancement, P5 - low, ---, julian.maurice, Pushed to Master , REST API: Use newer version of Swagger2
07:12:54 <tcohen> I'd like to promote it to a dev meeting
07:12:58 <kidclamp> bug 16699
07:12:59 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16699 enhancement, P5 - low, ---, koha-bugs, Signed Off , Swagger: Split parameters and paths, and specify required permissions for resource
07:13:13 <tcohen> so people can give their opinions
07:13:29 <cait> maybe good to send to the mailing list too before the next meeting
07:13:35 <cait> so people get time to look into it
07:13:45 <tcohen> good idea, I can send that email
07:14:17 <cait> #action tcohen to send an email to the list about 'splitting the swagger files' - bug 16699
07:14:27 <cait> ok, let's move on - more REST
07:14:43 <tcohen> yeah, I need to REST :-P
07:15:22 <cait> #topic General development discussion
07:15:43 <cait> hope people are not grumpy with me - I added questions about 2 topics I have stumbled on/being thinking about
07:16:05 <cait> so the first is: Is the REST API optional or mandatory (when you install Koha)
07:16:15 <cait> triggered was this by kidclamp's patch on bug 8030
07:16:16 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8030 enhancement, P5 - low, ---, nick, Signed Off , Change pickup location of a hold from patron record
07:16:33 <cait> and the fact that it was not working for me - as my REST stuff doesn't appear to be configured correctly yet
07:16:57 <cait> is there a general consensus about this kind of patch that we shoudl be using the API in the GUI already?
07:17:11 <cait> and if we do that, is it production ready? (secure, installs nicely, etc)?
07:17:36 <cait> one thing i noticed is that mojo etc. is still optional in PerlDependencies.pm
07:17:57 <tcohen> the REST api code has been deployed into users' installs since it was introduced
07:18:37 <tcohen> the original patches enabled it only on tarball/git installs
07:18:56 <tcohen> because the package's apache configuration files hadn't been tweaked
07:19:32 * tcohen re-reads the questions
07:20:08 <drojf> cait: what reasons could there be to keep it optional?
07:20:18 <drojf> (as far as it is tested, secure etc)
07:20:28 <cait> if it doesn't install well out of the box - it's not documented to activate (woudl be one reason for me)
07:20:35 <Joubu> if it's not ready yet
07:20:44 <cait> becuase the patch from kidclamp will put it in the middle of Koha so people will stumble upon it if it doesn't work :)
07:20:49 <fredericd> #info Frédéric Demians
07:20:50 <khall> cait: imo it's ready and necessary
07:20:56 <cait> or if there are security concerns - like permission problems
07:21:00 <khall> with a few more tweaks
07:21:01 <cait> i am not against it - hope that's clear
07:21:06 <cait> i'd just like us to be on the same page
07:21:07 <Joubu> The problem we have is that it's not ready yet and we'd like to use it from Koha
07:21:11 <cait> and look out for potential problems in production use
07:21:27 <cait> like fixing PerlDependencies etc.
07:22:03 <cait> ok, 2 different opinions
07:22:14 <cait> Joubu: can you tell what's missing in your eyes right now?
07:22:34 <drojf> FYI i have reverted bug 17030 from 16.05.03 for the debian package, because we lacked permission settings and it (if i got it right) allowed holds to be placed by everyone
07:22:35 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17030 enhancement, P5 - low, ---, tomascohen, Pushed to Stable , Configure the REST api on packages install
07:22:38 <cait> one more questio maybe woudl be about backporting REST API work to the stable releases atm
07:22:45 <Joubu> I have no idea, just repeating what I heard
07:22:52 <cait> if we say we will have it ready for 16.11 - but atm things are changing too much or so
07:23:00 <Joubu> but permission is a blocker
07:23:12 <cait> it's a mighty API.. which is cool, but also has me a little worried
07:23:19 <cait> :)
07:23:26 <kidclamp> bug 14868
07:23:27 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14868 enhancement, P5 - low, ---, larit, Needs Signoff , REST API: Swagger2-driven permission checking
07:23:53 <tcohen> I have an idea of what is missing
07:24:02 <tcohen> some love :-D
07:24:07 <khall> tcohen: can you summarize?
07:24:12 <khall> ; )
07:24:19 <drojf> lol
07:24:21 <tcohen> a simple search for REST on BZ
07:24:35 <gaetan_B> hello
07:24:36 <tcohen> will show that people have invested lots of time in two things
07:25:16 <tcohen> 1) create a good basis for defining endpoints and handling permissions seemlessly, using state-of-the-art technologies
07:25:36 <tcohen> I'm talking about having the API fully documented with a Swagger 2.0 spec
07:25:45 <tcohen> and the bug kidclamp mentioned
07:25:53 <tcohen> is the most important piece
07:25:56 <Joubu> IMO we need a list of people willing to be involved in the maintenance of the REST API
07:26:13 <tcohen> 2) there are lots of bugs introducing new endpoints
07:26:32 <cait> #info lots of REST related patches on bugzilla, focusing mostly on 2 things: 1) permission handling and documentation, 2) adding new endpoints
07:26:45 <tcohen> from a first look, we can notice people are writing endpoints so the UI can be fully rendered using the REST api
07:27:11 <tcohen> "need a dropdown with the list of branches? here's an endpoint"
07:27:12 <tcohen> etc
07:27:15 <khall> api devs++
07:27:47 <cait> the problem is we need people testing them - and we shoudl be careful about permissions/prefs taken into account/terminology :)
07:27:48 <kidclamp> Joubu: why do we need a specific list for maintaining this above other things?
07:28:11 <tcohen> cait: I agree
07:28:20 <cait> kidclamp: i think he meant people dedicated to look after it
07:28:23 <Joubu> currently there are patches, but just few people are involved
07:28:27 <cait> the patches get stuck right now - not a lot of experts
07:28:46 <Joubu> I'd like to know who is going to write/test/qa these patches
07:29:02 <Joubu> and who will fix bugs
07:29:16 <cait> I don't feel ready to test/qa - I'd like to learn - either online sometime or maybe in marseille
07:29:18 <drojf> somebody should do a dev intro in marseille
07:29:55 <drojf> volunteers? :P
07:29:59 <tcohen> I'd like to clarify something
07:30:00 <Joubu> (I've asked the same question on the ML but did not get answer from the involved people)
07:30:30 <tcohen> most functionality comes from the Koha::* classes
07:30:51 <tcohen> the mighty REST api is just a layer on top of that
07:31:00 <tcohen> routing calls to the right classes
07:31:14 <Joubu> s/is/must be
07:31:16 <khall> agreed!
07:31:17 <tcohen> which now has a rudimentary permission layer
07:31:37 <tcohen> which is about to get steroids with bug
07:31:50 <tcohen> bug 14868
07:31:51 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14868 enhancement, P5 - low, ---, larit, Needs Signoff , REST API: Swagger2-driven permission checking
07:32:10 <tcohen> what the guys do in that patches
07:32:41 <tcohen> is letting us declare the needed permissions, on the swagger file
07:33:08 <tcohen> so the API now will also provide more documentation, and a permission check schema
07:33:12 <tcohen> that makes code simpler too
07:33:25 <tcohen> I think we definitely need a workshop on this
07:34:31 <kidclamp> so for now we need people leading, but should be community maintainable without difficulty is what I hear tcohen
07:35:56 <tcohen> we need to make interested parties get involved
07:36:11 <tcohen> i'm not sure why they aren't
07:36:48 <tcohen> but I don't see the REST api as a complicated piece of code
07:37:27 <tcohen> maybe the V1.pm could get complicated with the permission checking layer
07:37:56 <tcohen> but look at this
07:37:57 <tcohen> http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=Koha/REST/V1/Patron.pm;h=2851308e7c34d78925972959438c28f4aa0782e8;hb=HEAD
07:38:16 <tcohen> if you remove the permission checking from that code
07:38:29 <tcohen> (because it is moved somewhere else by the mentioned patch)
07:38:43 <tcohen> you just have a couple calls to Koha::* libs
07:39:07 <cait> could it be a good idea to say no backports for now until we have sorted those base patches?
07:39:08 <khall> that is just lovely ; )
07:39:11 <tcohen> even the permission check lines are… what you'd expect
07:39:46 <Joubu> I'd even say no push to master
07:40:28 <cait> hm why not?
07:40:30 <khall> um, how do you propose we handle it then Joubu?
07:40:51 <Joubu> I meant to push of patches using the REST API
07:41:01 <Joubu> no the patches of the REST API
07:41:44 <khall> Joubu: I understand now, you mean don't push new endpoint patches until we get these mechanics fixing patches in place, right?
07:41:49 <kidclamp> block them with 14868, they all depend on that and can't be pushed until after
07:42:02 <tcohen> I agree we need some level of completeness before we make the decision to allow the REST to be used from the UI
07:42:27 <Joubu> I was thinking about bug 8030 (sorry kidclamp)
07:42:28 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8030 enhancement, P5 - low, ---, nick, Signed Off , Change pickup location of a hold from patron record
07:42:35 <tcohen> Joubu refers to patches that USE the endpoints
07:42:59 <kidclamp> that was what I meant, make it depends on the necessary infrastrcuture bugs
07:43:38 <khall> yes, that's sensible
07:44:02 <cait> cool
07:44:12 <Joubu> tcohen: since you looked at the patch deeper than me, could you send an email to summarise the situation?
07:44:21 <tcohen> alright
07:44:28 <cait> #idea don't backport REST API patches atm, until infrastructure is sorted out
07:44:35 <tcohen> I think I already volunteered for that
07:45:23 <cait> #idea make new patches using REST in the GUI depend on the infrastructure bugs, especially bug 14868
07:45:24 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14868 enhancement, P5 - low, ---, larit, Needs Signoff , REST API: Swagger2-driven permission checking
07:45:39 * cait is glad about the discussion
07:45:42 <tcohen> I think only 16.05 has got the REST api on packages
07:46:07 <tcohen> and fredericd is aware of the issues that prevent it to be enabled by default
07:47:06 <cait> can i add another question?
07:47:20 <drojf> if 14868 is not backported to 16.05 i think 17030 should be reverted
07:47:41 <drojf> fredericd: what do you think?
07:47:44 <cait> I taked to fredericd yesterday about the pending bad fines bug
07:47:50 <tcohen> that's fredericd's call, but yes
07:47:51 <cait> he said maybe he could do an additional earlier release
07:47:54 <cait> once we got that in
07:48:03 <cait> we coudl also use it to fix that
07:48:41 <fredericd> I agree with drojf. 17030 should be reverted
07:48:54 <fredericd> From now, I will skip any REST related patch
07:50:21 <tcohen> fredericd: we could patch /holds too
07:50:40 <tcohen> but it seems the real solution is so close :-D
07:51:45 <tcohen> I wrote a POC for bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16815
07:51:46 <huginn> 04Bug 16815: critical, P5 - low, ---, julian.maurice, ASSIGNED , API routes to list, create, update, delete holds need permissions
07:53:13 <fredericd> Without modifying Apache conf, is it possible to exploit hold security flaw?
07:53:45 <tcohen> the /api endpoint shouldn't be available without tweaking the apache files
07:53:50 <drojf> there is no way to reach the api if it's not in apache
07:53:50 <cait> hm with a package install probably? tcohen?
07:54:03 <drojf> (i hope)
07:54:10 <cait> i thought it auto-activated
07:54:13 <cait> on 16.05?
07:54:26 <drojf> cait: i reverted 17030 before i built the package. so no
07:54:28 <fredericd> reverting 7030 will fix that in 16.05
07:54:32 <cait> ah ok
07:54:37 <cait> bug 17030
07:54:38 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17030 enhancement, P5 - low, ---, tomascohen, Pushed to Stable , Configure the REST api on packages install
07:54:50 <cait> i thought that was in - so that's where i got confused
07:54:53 <drojf> thanks to tcohen for pointing that out btw
07:55:08 <fredericd> tcohen++
07:55:16 <eythian> hi
07:56:27 <tcohen> hi eythian
07:56:32 <cait> ok, another question from me? :)
07:56:54 <tcohen> yes
07:57:06 <cait> one of the patches, i will find the bug in a moment, adds the ability to see your own checkouts/renew your own mateirals
07:57:10 <cait> this doesn't require any permission
07:57:20 <cait> so if the api is there, anyone can use it - without the library knowing
07:57:31 <cait> it gives me a bit of a headache to be honest - i'd like to know how others see it
07:57:40 <eythian> sounds like an awful idea
07:57:58 <cait> that's my feeling, but so far i feel a bit lonely/paranoid .)
07:58:18 <cait> i'd like it better if you coud get for aexample an api key
07:58:21 <cait> that the library can revoke
07:58:22 <tcohen> cait: if I understand correctly
07:58:38 <tcohen> you mean that there's a bug proposing a REST endpoint, which implements it wrong?
07:58:42 <cait> bug 13895
07:58:43 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13895 new feature, P5 - low, ---, julian.maurice, Signed Off , Add API routes for checkouts retrieval and renewal
07:58:46 <khall> cait: it should require either 1) your login has the necessary permissions to view / modify checkouts or 2) the checkouts are your own ( for viewing )
07:58:53 <cait> it requires a login
07:58:57 <cait> but you can't control use
07:59:14 <cait> it mimicks what you can do with an opac access
07:59:18 <eythian> ah
07:59:23 <eythian> not so awful then
07:59:37 <tcohen> if you can do it in the OPAC right now, there's no difference
07:59:38 <cait> but for me... API is a different level of complexitiy
08:00:27 <cait> there is also ths bit as part of the big patch: https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=54766
08:00:30 <khall> cait: why do you think that? Giving patrons the ability to access their data via the api is a *good* thing!
08:00:53 <tcohen> cait: suppose you have a button in the OPAC, which allows logged users to renew stuff
08:00:58 <cait> fully automated access... not seeing any hints the library might have added - maybe getting around limitations only implemented in the templates...
08:01:14 <tcohen> anyone can point the browser to the .pl with the right arguments
08:01:15 <drojf> if they are only in the templates then that is a bug now
08:01:23 <cait> true
08:01:23 <tcohen> and renew their stuff without using 'our' button
08:01:26 <drojf> if we want to have an API
08:01:35 <drojf> or we can't have one :P
08:02:16 <tcohen> the API is just a way to organize things
08:02:19 <kidclamp> if your patrons are bold enough to research and use the API directly you should get them signing off on bugs :-)
08:02:29 <drojf> heh
08:02:29 <tcohen> hahaha
08:02:53 <cait> ok, so paranoid :)
08:03:06 <tcohen> we should have good logging facilities
08:03:10 <khall> even better, it means that Koha can be integrated into other apps
08:03:18 <tcohen> for example, we could have a special 'api' interface
08:03:18 <cait> other sofware seem to require something like an api key - so youwould know hwo uses your api
08:03:30 <khall> tcohen: good idea
08:03:30 <drojf> folio will be so happy
08:03:32 <drojf> :P
08:03:41 <drojf> or, ebsco
08:03:58 <tcohen> or my customer's student's management system
08:04:08 <khall> drojf: good point, the api will make folio integration much simpler
08:04:28 * ashimema_ hints at OAUth
08:04:33 <ashimema_> OAuth.. even
08:04:41 <khall> lol
08:04:41 <ashimema_> that's it's entire reason for being
08:04:43 <tcohen> cait: the api-key stuff if for system<->system integration
08:05:01 <tcohen> right now, the API only implements cookie-based auth
08:05:33 * ashimema disappears again before he slates our api implementation ;)
08:05:46 <kidclamp> I think cait in the end patrons shouldn't be able to do anything via API they can't do via the opac, so it shouldn't be any different
08:06:07 <tcohen> with the same restrictions
08:06:28 <cait> ok
08:06:39 <cait> i will log that :)
08:06:48 <tcohen> that's why it is important that people get involved
08:06:52 <tcohen> people that know Koha a lot
08:06:57 <tcohen> can I give another example
08:07:01 <ashimema> proper access control would take into account.. who's data your trying to chance, who's trying to change it and what application is doing the change on behalf of the person
08:07:06 <drojf> tcohen: doing the workshop in marseille? :P
08:07:06 <cait> #info patrons will be able to use the REST API to do, what they can do in the OPAC, but not more
08:07:18 <cait> #chair drojf
08:07:19 <huginn> Current chairs: cait drojf
08:07:21 <cait> phone
08:07:31 <drojf> err i only had one coffee
08:07:43 <ashimema> i.e the cookie or token your using for authentication should include those three details
08:07:56 <cait> #chair tcohen
08:07:56 <huginn> Current chairs: cait drojf tcohen
08:07:59 <ashimema> so for the koha case
08:08:06 <tcohen> cait: https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=54767
08:08:08 <ashimema> the cookie you get when you log in to the opac says..
08:08:28 <ashimema> I'm person X, using interface 'OPAC'.
08:08:50 <ashimema> (which defaults to limiting them to only chaning person x's data and limits them to opac only actions.
08:09:01 <ashimema> when you login to the staff client the cookie says
08:09:13 <ashimema> I'm Person X, Using interface 'Staff'..
08:09:56 <ashimema> then any actions you undertake on Person Y may or may not be permissible because your aware of what person c is allowed to do under the 'staff' interface.
08:10:31 <tcohen> ashimema: we are missing the interface data I think
08:10:32 <drojf> person x? :P
08:10:49 <ashimema> in the OAuth world.. your efectively just adding more 'interfaces' and letting the person involved choose what that interface is allowed to do on thier behalf with their login
08:10:51 <ashimema> i.e
08:11:19 <ashimema> Person X logs in to Koha, then grant Interface Z privileges to undate their username.
08:11:44 <ashimema> When person X then logs into Interface Z, the system knows that all Interface Z is allowed to do is change the username.
08:12:01 <ashimema> (or rather.. the system knows all that interface Z is allowed to do is change the username)..
08:12:11 <ashimema> the interface can optionally look that up or not..
08:12:28 <drojf> so a user would allow an android app to log in and show account details. like a twitter app or something
08:12:28 <ashimema> but form the api security perspective.. Interface Z will never be allowed to do more than change the username
08:12:29 <tcohen> ashimema: are you attending Marseille?
08:12:36 <ashimema> I am
08:12:47 <ashimema> though I still need to book my train and hotel
08:12:56 <tcohen> so the "workshop" thing is dealed with
08:12:58 <tcohen> :-P
08:13:07 <ashimema> ?
08:13:21 <tcohen> you need to talk about REST and Swagger
08:13:29 <ashimema> haha.. sure
08:13:30 <tcohen> *dealt*
08:13:45 <tcohen> cait: are you back?
08:13:45 * ashimema hints it's changed it's name lately.. it's no  longer 'Swagger', it's 'OpenAPI'..
08:14:04 <tcohen> yeha, I noticed yesterday
08:14:11 <drojf> cool, nore confusion
08:14:13 <drojf> more
08:14:29 <drojf> are we done with REST discussion?
08:14:43 <tcohen> I want to clear cait's fears, and encourage her to get involved in reviewing some REST stuff
08:14:45 <ashimema> ooh..
08:14:50 <ashimema> I didn't realise we were in a meeting..
08:14:55 <ashimema> apologies for that diversion then ;)
08:15:02 <drojf> ashimema: good contributions though
08:15:04 <ashimema> #info Martin Renvoize - PTFS Europe
08:15:07 <ashimema> lol
08:15:10 <tcohen> so I need to explain this https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=54767
08:15:23 * ashimema should put meetings in the diary and set alarms.. lots of alarms
08:16:30 <tcohen> I need a couple hours of sleep
08:16:32 <drojf> tcohen: do we wait or do you want to do it later maybe?
08:16:48 <drojf> no idea how long she will be on the phone
08:17:02 * ashimema will read that lot probably late this evening.. too much to do today already :(
08:17:05 <tcohen> i just want to make a point
08:17:16 <tcohen> anyone can look at that 'swagger' file
08:17:31 <tcohen> and review permissions that are required for each endpoint/action
08:17:47 <ashimema> indeed they can
08:17:56 <tcohen> specially people like cait, that know Koha's business with lots of detail
08:17:57 <ashimema> that's a good thing in my opinion
08:18:15 <tcohen> there's no need to engage in the technical part of the problem
08:19:06 <drojf> #info REST api permissions can be reviewed in file, see https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=54767
08:19:23 <tcohen> so, our product owner can review it and with a simple reading and notice issues
08:19:34 <tcohen> the code of course should respect those definitions hhe
08:20:00 <drojf> i assume that finishes the api permission part for now?
08:20:01 * tcohen goes to sleep
08:20:05 <tcohen> yes
08:20:11 <tcohen> later #koha
08:20:17 <kidclamp> bye tcohen
08:20:20 <drojf> ok. then if there is nothing more for the REST api i would mov eon
08:20:24 <drojf> night tcohen
08:20:28 <kidclamp> agreed
08:20:40 <drojf> #topic Highlight easy to test bugs for beginners
08:20:55 <drojf> we had that last time on the agenda and nobody knew what to say about it
08:20:58 <kidclamp> This was something cait and I discussed a while back
08:20:59 <drojf> kidclamp: was it yours?
08:21:05 <kidclamp> yes
08:21:11 <drojf> ah cool, can you explain
08:21:13 <drojf> ?
08:21:36 <kidclamp> It seems that often when people want toget involved they want to know easy bugs to sign off/test
08:22:03 <kidclamp> It would be easy enough to either use the 'Academy' keyword all year round, or have a new keyword tomark beginner bugs
08:22:43 <kidclamp> complexity is sort of helpful there, but isn't always filled out and sometimes a single patch is complex but depends on complicated things
08:22:43 <drojf> i think we should use a new one maybe
08:23:00 <khall> we could also have a "testing complexity" pulldown in addition to "patch complexity"
08:23:41 <drojf> that sounds nice, but does BZ allow that?
08:23:49 <drojf> no idea how the config works
08:24:14 <kidclamp> 'testing complexity' is a bit more complicated I think - is it complex to rquire setting up 50 users and branches and checking out a bunch of items, or just tedious :-)
08:24:15 <drojf> that might be even better than a tag
08:24:46 <khall> kidclamp: I would just call that tedious ; )
08:24:52 <drojf> kidclamp: we should have a sample db that just has a bit of everything
08:24:58 <khall> digging a ditch is not complex, but it is tedious
08:25:17 <Joubu> drojf: we have the sandbox DB already
08:25:19 <drojf> but i agree, it's not compley
08:25:34 <kidclamp> but asking a volunteer to dig a ditch may not encourage him to return ;-)
08:25:42 <drojf> Joubu: but they don't have active checkouts and holds and acq data and stuff, do they?
08:26:00 <khall> ok, first two settings are "Simple" and "Simple but tedious" ; )
08:26:05 <drojf> lol
08:26:22 <kidclamp> I'll support that
08:26:28 <Joubu> drojf: no indeed
08:26:48 <Joubu> nobody will test these ones...
08:27:03 <cait> sorry, reading back now
08:27:29 <drojf> khall: i would call that… extra…something. making it a good thing people will learn more about koha :P "simple - special experience"
08:27:53 <khall> drojf: love it!
08:27:59 <kidclamp> much better
08:28:54 <drojf> ok then somebody needs to talk to rangi asking about the testing complexity thing? if that is an option it looks like we all are in favour of it?
08:29:34 <kidclamp> +1
08:29:48 <drojf> #idea instead of a keyword, add "testing complexity" to BZ
08:30:20 * cait gives up on reading back fast enough
08:30:22 <kidclamp> so will developers etc. agree to look for the 'omg complex!' bugs
08:30:28 <cait> any questions or so?
08:30:42 <drojf> no
08:31:02 <cait> @later tell tcohen - i want to get involved, will you sit down with me to teach the basics? ;)
08:31:02 <huginn> cait: The operation succeeded.
08:31:02 <khall> heh
08:31:06 <drojf> cait: i info'd what tcohen wants you to look at
08:31:12 <drojf> regarding api permissions
08:31:15 <kidclamp> because that is one downside to complexity - complex bugs exist and need attention
08:31:51 <kidclamp> or do we only makr easy ones
08:31:56 <drojf> kidclamp: the complexity is already there without the label. i think devs know that ;)
08:32:02 <cait> currently there is lots of scary stuff in needs sign-off
08:32:05 <khall> I think another testing complexity setting should be "Needs command line access"
08:32:08 <cait> it would be good to get some devs in there for signing off too
08:32:14 <khall> aka can't be tested in a sandbox
08:32:25 <cait> so we can make easy ones esier to spot... but we also need people to help out with complex stuff
08:32:28 <drojf> but it helps newbies if they can find easier ones
08:32:31 <kidclamp> "testable on sandbox" as well
08:32:35 <cait> yep agreed
08:32:50 <cait> maybe 'system architecture'
08:32:52 <cait> ?
08:32:54 <drojf> but testable on sandbox and easy or hard are different categories
08:33:04 <drojf> that should probably be an extra thing
08:33:15 <drojf> or we will have a lot of options in that box
08:33:20 <cait> maybe keywords woudl be easier
08:33:24 <cait> because you can have multiple
08:33:30 <kidclamp> I think don't have 'hard' or 'complex' just mark the simpler ones
08:34:09 <drojf> if we want to use the BZ api (eg a sandbox could check for the sandbox tastability), it should be separated
08:34:20 <drojf> testability
08:34:24 <drojf> tasty too
08:34:31 <kidclamp> yummy sand
08:34:41 <khall> kidclamp: I'm inclined to agree with you, that's less likely to scare people away from "hard to test" patches
08:35:36 <cait> sandbox_ready keyword?
08:35:58 <drojf> just sandbox
08:36:07 <drojf> or nosandbox, like i did with nowheezy
08:36:13 <drojf> it will be less to tag
08:36:14 <drojf> i guess
08:36:36 <kidclamp> I also wouldn't discourage use of 'Academy' year round still, there are those bugs that are very educational to testers - if we mark one right after academy and it isn't dealt with by next academy, probably still relevant?
08:36:41 <khall> yeah, I think nosandbox makes the most sense
08:37:17 <kidclamp> I would argue the other, mark the sandboxable so you can find those if you use one
08:37:38 <kidclamp> if you want to use a sandbox unmarked and nosandbox are equal
08:37:42 <cait> drojf: will you talk to rangi about adding the keywords?
08:37:56 <drojf> khall: nosandbox is something devs would have to add when they add the patch. sandbox could be something people add when actively looking for easy bugs to mark
08:37:58 <khall> so should we stick with "Academy" as the easy tag, and add the keyword "nosandbox" and "educational" ( aka tedious )
08:37:58 <kidclamp> 'sandbox' mark makes it stand out
08:38:27 <kidclamp> drojf +1
08:38:28 <drojf> so maybe sandbox makes more sense in this context
08:38:40 <khall> drojf: ok. I was just assuming most patches are sandbox testable
08:38:45 <cait> i think sandbox, nosandbox (so both can be marked when you see it) , but not totally sold on educational
08:38:52 <cait> Avademy for easy is ok for me
08:38:57 <drojf> khall: yes me too, i just thought about the workflow right now
08:39:06 <khall> works for me!
08:39:28 <cait> drojf: are you volunteering? or kidclamp?
08:39:53 <drojf> i don't know if the academy is happy if the academy tag is used for everyone, because that will make it impossible for them to claim a few bugs when the academy actually happens
08:40:14 <drojf> "claim"
08:40:26 <kidclamp> don't they usually call out for people to mark bugs around that time?
08:40:48 <khall> drojf: true, maybe tis better to just create a new less special keyword
08:40:59 <drojf> easy, beginner, newbie
08:41:02 <drojf> something like that
08:41:05 <kidclamp> I am happy for it to be a new keyword - I just wanted a keyword and a complexity :-)
08:41:12 <kidclamp> if we were going complexity route
08:41:31 <cait> new_kewyword+1
08:41:36 <khall> kidclamp: can you propose a list of complexities?
08:41:56 <drojf> cait: i volunteer kidclamp because it is his topic :P
08:41:59 <kidclamp> yes, for next meeting - can be a general meeting discussion I think
08:42:21 <cait> #action kidclamp to talk to rangi about adding new keywords as discussed in the meeting to indicate easy bugs for beginners and testing complexity
08:42:27 <cait> ah
08:42:29 <cait> or next meeting
08:42:39 <cait> #action kidclamp ... or make a suggestion for the next meeting
08:42:41 <kidclamp> I will talk to rangi before
08:42:45 <cait> sounds good
08:42:48 <kidclamp> and then make suggestion
08:42:53 <cait> are we ok to move to action items from last meeting?
08:42:59 <cait> we are running late today :)
08:43:15 <kidclamp> yes. move ahead
08:43:19 <cait> #topic Updates from the QA team
08:43:27 <cait> no updates from me - please look at critical bugs, link on the agenda
08:43:30 <cait> Joubu: ?
08:43:38 <Joubu> nothing new
08:44:00 <cait> sorting bug 17135 fast would be bood
08:44:01 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17135 blocker, P5 - low, ---, koha-bugs, NEW , Fine for the previous overdue may get overwritten by the next one
08:44:01 <cait> good
08:44:11 <cait> it's a problem in the stable version
08:44:49 <Joubu> you are 3 on it, so decided to stay away from it. Do you need help?
08:45:03 <cait> I thin the missing piece now is a database update
08:45:07 <cait> to clean up
08:45:21 <cait> FU double ups a hopefully last time
08:45:41 <cait> and a set of eyes probably doesn't hurt - i didn't have time for testing
08:46:08 <cait> the patch set is on bug 14390 actually
08:46:09 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14390 major, P5 - low, ---, kyle, Signed Off , Fine not updated from 'FU' to 'F' on renewal
08:46:36 <Joubu> ok will have a look at the updatedb
08:46:57 <cait> moving on
08:47:03 <cait> #topic Actions from last meeting
08:47:16 <cait> bag to add a note to the next release notes - I got on idea what that was about!
08:47:23 <cait> http://meetings.koha-community.org/2016/development_irc_meeting_13_july_2016.2016-07-13-14.08.html
08:47:36 <cait> Joubu is going to check if some performance testing can be  included in the qa scripts (launch a series of tests and compare diff)     Joubu to ask on the mailing list about which namespace scheme should be used for the 'export things'
08:47:37 <drojf> deprecation of wheezy i think
08:47:55 <cait> did we come to a conclusion about the export scheme?
08:47:59 <khall> Joubu: we may want to rerun the FU to F cleanup from bug 15675. Just keep that under your hat ( https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=48471&action=diff )
08:48:00 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15675 enhancement, P5 - low, ---, kyle, RESOLVED FIXED, Add issue_id column to accountlines and use it for updating fines
08:48:02 <Joubu> the namespace "discussion" is on http://lists.koha-community.org/pipermail/koha-devel/2016-July/042845.html
08:48:17 <Joubu> khall: k!
08:48:29 <cait> #info namespace discussion is on http://lists.koha-community.org/pipermail/koha-devel/2016-July/042845.html
08:48:41 <Joubu> I have started the benchmarks for QA tools: http://lists.koha-community.org/pipermail/koha-devel/2016-July/042844.html
08:48:46 <Joubu> but need feedback
08:48:59 <cait> #info Start for benchmarks for QA tools: http://lists.koha-community.org/pipermail/koha-devel/2016-July/042844.html Please comment!
08:49:18 <cait> khall to add new benchmark rule to the coding guidelines
08:49:32 <Joubu> and I think I have provided the list of bug numbers waiting for QA (search for "Move stuffs to Koha namespace" and related)
08:49:54 <cait> khall volunteers to focus on rewrite patches for QA
08:49:54 <cait> khall to provide a proof of concept for using React in Koha
08:49:54 <cait> khall to add react/angular and frontend build to to next agenda ;)
08:49:59 <khall> cait: I believe I did that in PERL24
08:50:16 <cait> thre were lots of action items
08:50:21 <cait> ok thx khall
08:50:23 <khall> cait: that could use some discussion.
08:50:29 <cait> which oneß
08:50:31 <cait> ?
08:50:42 <khall> React stuff
08:51:07 <cait> #info PERL24 was added after the last meeting: https://wiki.koha-community.org/wiki/Coding_Guidelines#PERL24:_Performance_and_cache_related_patches_should_include_benchmarks_of_some_sort_to_prove_their_effects
08:51:15 <cait> can we talk about it next dev meeting?
08:51:33 <khall> basically, many new js libraries ( like react ) require transpiling which means we need to use a tool like gulp to convert the React js files into regular js files
08:51:51 <khall> I don't think it's a big deal, but I wanted to bring it up.
08:52:04 <cait> i thin that might be related to owen's action item?
08:52:10 <cait> oleonard to start a mailing list thread about the frontend build tool ?
08:52:11 <khall> Most importantly, that requires developers to use npm
08:52:28 <khall> cait: yes, same thing basically
08:52:37 <cait> can you please add this to the next agenda?
08:53:10 <cait> #action khall to add react and related topics to next dev meeting agenda
08:53:12 <cait> ;)
08:53:22 <khall> can do! I think we will end up using gulp most likely
08:53:26 <cait> i think Joubu has made a list of bugs available in his summaries
08:53:36 <cait> let's seet date and time for the next meeting
08:53:49 <khall> the big note is that we already make developers use node/npm for dealing with opac css via less
08:54:07 <cait> #topic Set time of next meeting
08:54:08 <khall> so there's already precedent for needing/using node/npm as a Koha developer
08:54:24 <cait> September 28?
08:54:34 <cait> 21 utc?
08:54:34 <wahanui> 21 utc is fine and might be better for local time adjustments.
08:55:30 <kidclamp> I like 21 UTC
08:55:39 <Joubu> it's always too late for everybody
08:55:43 <Joubu> unless kidclamp
08:55:46 <cait> and nz
08:55:46 <kidclamp> :-)
08:55:59 <cait> I thought we ere nice to europe this time
08:56:06 <cait> so could try being nice to others... :)
08:56:09 <cait> argentina shoudl be better too
08:56:28 <khall> yeah
08:56:36 <cait> is that an ok?
08:56:48 <Joubu> k
08:56:52 <cait> #agreed Next meeting will take place on September 28, 21 UTC
08:56:53 <cait> thx a lot
08:56:56 <cait> #endmeeting