14:01:22 #startmeeting Development IRC meeting 15 January 2020 14:01:22 Meeting started Wed Jan 15 14:01:22 2020 UTC. The chair is ashimema. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:22 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:22 The meeting name has been set to 'development_irc_meeting_15_january_2020' 14:01:31 #topic Introductions 14:01:47 #info Martin Renvoize, PTFS-Europe 14:01:58 #info Joonas Kylmälä 14:02:06 #link https://wiki.koha-community.org/wiki/Development_IRC_meeting_15_January_2020 Agenda 14:02:20 please use "#info" in front of your introduction to have it show up in the automatic minutes 14:02:39 * ashimema sits on hands and waits patiently 14:03:11 #info Tomas Cohen Arazi, Theke Solutions 14:03:48 #info Thomas Dukleth, Agogme, New York City 14:04:47 #info Katrin Fischer, BSZ, Germany 14:04:59 sorry, got distracted 14:05:10 shall we continue 14:05:20 #topic Announcements 14:05:27 yes please 14:05:32 I think people will drop in 14:05:37 ping qa_team 14:05:44 ping qa_team? 14:05:52 ping qa team? 14:06:09 rmaints? 14:06:09 hmmm... rmaints is talljoy, lucas, hayley 14:06:17 qa_teamp? 14:06:17 #info Magnus Enger, Libriotech, Norway 14:06:18 * qa_team? 14:06:21 qa team? 14:06:21 qa team are the real gatekeepers, send cookies their way 14:06:24 #info Nick Clemens, ByWater Solutions 14:06:26 * cait gives up 14:06:46 qa_team? 14:06:46 hmmm... qa_team is cait Joubu marcelr kohaputti josef_moravec tcohen kidclamp khall 14:06:51 Joubu id OFF 14:06:55 thx kidclamp :) 14:07:20 #info Marseile Hackfest20 - 23rd-27th March.. get your flights/trains/hotels booked and join us :) 14:07:40 lots to discuss today, so good to wake up some more people 14:08:05 #info Kohacon20 - Registrations are open, get yourself registered and start looking into visa applications 14:08:18 any other announcements I've missed? 14:09:01 #info There will be no Academy this year - feel free to grab any Academy bugs! 14:09:20 good one cait.. I forgot that 14:09:41 Yippee, build fixed! 14:09:41 Congratulations! 14:09:41 Project Koha_Master_D8 build #620: FIXED in 31 min: https://jenkins.koha-community.org/job/Koha_Master_D8/620/ 14:10:03 #info Remember to use the `Mentored-by` line in your git commits if you'd like to help someone new :) 14:10:10 YAY 14:10:11 #topic Update from the Release manager 14:11:37 #info We are now in a experimental period of pushing bigger new features, refactors and enhancements. So far, it seems to be going well, with lots of exciting new developments having made the cut and quick followups fixing issues as they arrise. 14:12:25 \o/ 14:12:42 #info Thanks go out to the QA team and Testers for helping things move along.. and some of the usual suspects and authors for acting quickly when asked to fix the odd inevitable test failure during such a period. 14:12:49 thanks for focusing on the maintanance side for koha code, ashimema ! 14:12:52 got team :) 14:13:51 go team :) 14:15:21 that's it from me really.. we have more criticals and majors than I'd like in the queue.. but we can raise that during the QA update section 14:15:23 so.. 14:15:37 #topic Updates from the Release maintainers 14:15:38 rmaints? 14:15:39 rmaints is probably talljoy, lucas, hayley 14:15:47 is the dashboard up to date? 14:15:49 yes, the criticals need some work - also the old ones need checking so we get the number down again 14:15:56 tcohen: yes? 14:16:14 Project Koha_Master_D9_MDB_Latest build #70: UNSTABLE in 38 min: https://jenkins.koha-community.org/job/Koha_Master_D9_MDB_Latest/70/ 14:16:33 dashboard is up to date, but we need to continue doing an audit of the majors.. at least some can probably be de-escalated 14:16:33 ok, it felt like a cron routine didn't run, but only noticed on the patches submitted list 14:16:48 lets tackle the majors ASAP! 14:16:54 it's all live as far as I'm aware 14:16:55 no crons involved 14:17:31 #info Rmaints will be anouncing string freeze iminently for their respective branches 14:17:50 #topic Update from the QA team 14:17:54 cait :) 14:18:04 I know :) 14:18:43 #info Queue for QA team is around 80 atm - goal should be to push that a bit lower, but the bigger patches also take more time to review 14:19:04 #info There is a lot of major bugs right now that auditing and fixing 14:19:12 ashimema: remind me of your keyword? 14:19:34 #info There is a keyword RM_priority that should help to select the more urgent ones 14:19:47 #info We have 106 `majors` in the queue and need to do some bug wrangling as well as encourage some movement on the NEW bugs. 14:19:58 keyword for what? 14:20:07 got it i think, RM_priority 14:20:26 anything else? kohaputti, kidclamp? 14:20:45 there's also `rel_20_05_target` which has a list of 65 bugs that nearly made the cut for 19.11 and should be easy to pick off for 20.05 14:20:48 just working on ES bugs and fixes 14:20:53 no, just huge shout out to Joubu for doing 28 passed qa already this month 14:20:59 Joubu++ 14:21:09 yep, Joubu++ :) 14:21:15 JOubu++ 14:21:24 @karma JOubu 14:21:24 cait: Karma for "JOubu" has been increased 783 times and decreased 2 times for a total karma of 781. 14:21:34 not case sensitive it seems :) 14:21:35 moving on? 14:22:04 Joubu is feeling slight burn out on QA btw.. if we could find a few of his bugs to work through the process it'll help re-motivate him 14:22:17 that's a very good point 14:22:21 ok... moving on 14:22:35 also a lot of his is good stuff and fixes 14:22:35 #topic General development discussion (trends, ideas, ...) 14:22:49 shoudl we work from top to bottom? 14:23:08 cait, sounds good to me 14:23:10 #chair cait 14:23:10 Current chairs: ashimema cait 14:23:22 ashimema: me? 14:23:23 it has been said that cait is really good at running into things 14:23:29 yup 14:23:37 oh yep... i have to sore spots as prove wahanui 14:23:52 ok, the first we are looking at is INVOICES 14:23:58 #link https://wiki.koha-community.org/wiki/Acquisitions_invoices_endpoint_RFC 14:24:02 lol 14:24:07 tcohen: can you explain the idea of close? 14:24:33 you mean closed 14:24:45 yes 14:24:48 I assumed the close comes from the close_date value 14:24:55 there is no closed in the db 14:24:57 i.e. whether it is defined or not 14:25:01 well, in the code and templates we usually check if closedate is set to something 14:25:03 yup 14:25:06 and render 'Closed' 14:25:29 in JavaScript it will be handy to just have a boolean with that calculated 14:25:43 so that would be an 'extra calculated value' that we expose? 14:25:43 so you write if ( invoice.closed ) { ... } 14:25:56 cait exactly, we do it in several places 14:25:57 and when you set 'closed' it will put in the current date? 14:26:08 POST I should say 14:26:40 right, there should be a route POST /.../invoices/:invoice_id/close { close_date: ... } 14:26:44 or similar 14:27:03 ok 14:27:04 is close_date readonly? 14:27:12 I haven't thought about that yet, I was focusing more on the mappings to get feedback 14:27:31 I think we will agree on shipping_cost_budget_id = shipping_cost_fund_id 14:27:32 and I agree.. we should use 'date_closed' to be clear of it's content I feel 14:27:39 past tense 14:27:41 close_date = date_closed - what is better semantically? 14:28:00 i see we mostly have date at the end, so withdrawin that suggestion 14:28:05 maybe closing_date? 14:28:06 cait, you mean shipping_cost_budget_id => shipping_cost_fund_id ? 14:28:10 cait, I agree with that 14:28:16 I might suggest closing_date . 14:28:18 sorry phone 14:28:29 I agree with thd 14:28:34 closing suggest future tense to me.. 14:28:38 I meant even closed_date . 14:28:46 can it/shoult it be in the future 14:28:46 #info Kyle M Hall, ByWater Solutions 14:28:53 ... as opposed to close_date 14:29:21 ... close_date seems to be grammatically difficult to apprehend. 14:29:27 I bet we don't have a patturn for date params... 14:29:33 isn't closing the noun? 14:29:39 i.e date_* vs *_date 14:29:54 closing is also fine. 14:30:02 Project Koha_Master_D9_My8 build #91: STILL UNSTABLE in 52 min: https://jenkins.koha-community.org/job/Koha_Master_D9_My8/91/ 14:30:09 closing would be customary 14:30:19 closing would allow for future 14:30:19 how have we put it in other end points / is there any with close/closing? 14:30:40 from what I see for consistency it shoudl be _date 14:30:47 but otherwise i think we don't have closing 14:30:50 If we use closing_date would be customary English. 14:30:57 we close subscriptions - but i woudl argue it's the wrong term there 14:31:13 it's more cancel/end 14:31:15 if we use `closing` then the `closed` boolean would need rethinking ;) 14:31:25 hm, no 14:31:26 * ashimema can't entirely remember how closed is used 14:31:29 ashimema++ 14:31:30 because that is the status 14:31:31 date_closed? 14:31:32 closed = 1 14:31:40 kohaputti: date at the end 14:31:43 :) 14:31:44 I meed the code that it uses cait 14:32:02 tcohen: which one do you want? 14:32:07 currently 'closed' = 'closedate contains anything, past, present or future' 14:32:12 i have a new idea actually 14:32:14 order_date 14:32:15 we have shipping_date already there 14:32:15 I'm readnig the code 14:32:20 closing a basket switches the status to ordered 14:32:24 but a 'future' closing date should not set closed to true 14:32:24 so closing_date would match with that 14:32:48 we are not very clear about that in all parts of the code, but a closed basket is ordered 14:33:05 an open basket is 'new' (unfinished, in progress) 14:33:17 we have a real mix of date vs date 14:33:37 even within endpoints... patrons for example has 'date_enrolled' and 'expiry_date' 14:33:42 cait, we are discussing invoice here, not basket 14:33:54 kohaputti: agh, you are right 14:34:05 sorry, the phone call threw me off a little 14:34:09 Having date before close as in date_closed seems counter to the preferred order of terms in variable naming unless time periods have importance over function. 14:35:09 lately, I prefered putting the function before, as in suggestor_id, billing_date 14:35:30 tcohen++ 14:35:30 * ashimema is happy either way around but likes consistency 14:35:31 but I don't have a strong opinion on this, I am all for consistency 14:35:56 so.. closed_date is fine by me.. 14:35:57 and I reckon we can improve our naming consistency 14:36:19 ashimema, but the other ones are future, like shipping_date 14:36:28 and I think it is 'closed' because I don't think we allow for closing an invoice in the future 14:36:32 Yes, if we develop or elicit principles, then we should apply them consistently including revisiting previous work. 14:37:18 shipping is one of those more evil english words.. I see it as a noun there and as such I don't attach a tense 14:37:20 lol 14:37:21 thd if you volunteer to review existing endpoints, I can implement the changes 14:37:21 closed_date it is 14:37:38 do we have other things for invoices? move on? 14:37:43 * thd always volunteers. 14:38:10 thd will be looking forward to that 14:38:38 There is a principle contradiction. 14:38:40 hmm, in the basket API RFC close_date was suggested 14:39:07 kohaputti: I did it very fast so I could get it reviewed 14:39:21 If we have some expectation of following the GUI, then either the API or the GUI needs changing ... 14:39:22 don't be strict on the original proposal, it is open for discussion 14:40:02 the GUI says close: i think 14:40:19 or closed... nm 14:40:21 ... Is shipping_cost_fund_id consistent with the GUI currently and not shipping_cost_fund_id? 14:40:30 yes 14:40:36 it's called shipping and fund 14:40:51 and id to be clear it requires an internal id 14:41:34 i know if we don't vote this, we will block tcohen's work 14:42:00 so could we agree on closed_date and *fund* ? 14:42:30 I can agree, how to vote? :) 14:42:38 +1 from me 14:42:40 good question 14:42:44 Also there are other API section comments preferring the use of the word price to the word cost. Price has more ambiguity. 14:42:47 is someone updating the wiki? 14:43:09 I haven't updated the wiki yet 14:43:25 @start vote "Can the Invoices endpoint be implemented as described on the wiki with the changes suggested and discussed today (closed_date, fund)? (yes, no, abstain) 14:43:25 cait: Error: No closing quotation 14:43:39 @start vote Can the Invoices endpoint be implemented as described on the wiki with the changes suggested and discussed today (closed_date, fund)? (yes, no, abstain) 14:43:39 cait: I suck 14:43:43 yes,... 14:43:47 help? 14:43:47 help is appreciated for bugs and keeping jenkins happy 14:44:06 cait, try adding the quotes 14:44:12 #vote yes 14:44:20 found the mistake 14:44:24 #vote yes 14:44:27 @startvote Can the Invoices endpoint be implemented as described on the wiki with the changes suggested and discussed today (closed_date, fund)? (yes, no, abstain) 14:44:27 cait: I'll give you the answer as soon as RDA is ready 14:44:28 i already had it that way, huginn`. 14:44:30 #yes 14:44:34 #vote yes 14:44:37 #vote yes 14:44:39 #vote yes 14:44:40 hm no 14:44:46 #startvote Can the Invoices endpoint be implemented as described on the wiki with the changes suggested and discussed today (closed_date, fund)? (yes, no, abstain) 14:44:46 Begin voting on: Can the Invoices endpoint be implemented as described on the wiki with the changes suggested and discussed today (closed_date, fund)? Valid vote options are , yes, no, abstain, . 14:44:46 Vote using '#vote OPTION'. Only your last vote counts. 14:44:50 I am sorry everyone :( 14:44:51 #vote yes 14:44:53 #vote yes 14:44:54 #vote yes 14:44:55 #vote yes 14:44:56 cait++ 14:45:10 thx ashimema 14:45:12 sorry.. I ws mid looking up how it worked again 14:45:15 how hard can it be? 14:45:30 hehe 14:45:39 endvote? 14:45:46 #endvote 14:45:46 Voted on "Can the Invoices endpoint be implemented as described on the wiki with the changes suggested and discussed today (closed_date, fund)?" Results are 14:45:46 yes (4): ashimema, cait, tcohen, kohaputti 14:45:50 next one 14:45:50 next one is probably by Jon Knight.. he's a customer (not that i've ever actually met him though in this case).. that'll get me brownie points all round :) 14:45:56 BASKETS 14:45:58 #link https://wiki.koha-community.org/wiki/Acquisitions_baskets_endpoint_RFC 14:45:58 wait 14:46:00 invoices.. 14:46:10 what about discussing the readonly for closed_date? 14:46:31 and the new endpoint for closing / opening the invoice 14:46:37 kohaputti I agree with having it read only 14:46:45 lets vote it 14:46:47 i think we only had the mapping so far - probably can be solved on the bug itself 14:46:55 tcohen: the readonly? 14:47:15 #startvote Shoudl we implement closed_date as readonly (yes, no, abstain) 14:47:15 Unable to parse vote topic and options. 14:47:17 I think I will refine the proposal with those details, lets vote the mappings 14:47:18 I don't have an opinion on this, I would prefer to get some info on pros and cons 14:47:20 oh gah. 14:47:51 ok, so better hash that out on the bug .) 14:47:58 shoudl not stop development for now 14:48:03 baskets then? 14:48:05 FTR 14:48:07 I'm up for leaving it to the developer 14:48:17 can you check on my comments on the wiki? 14:48:18 I'm working on the orders endpoint, which got pushed 14:48:34 I'm extending it so we can embed related objects on the response 14:48:40 that's why I need to have this mappings 14:48:51 I'm not jumping into developing those endpoints (yet) 14:49:07 I'm doing more barebones work 14:49:08 ok..lets just talk mappings for now 14:49:22 note vs notes.. 14:49:37 notes 14:49:40 we got the notes on the others, so that's just a consistency one 14:49:49 close_date = order_date 14:49:55 I would say it depends on how the field is constructed.. if if can return an array of notes then notes.. if it returns a single field.. then 'note' 14:49:55 that was what i meant earlier... 14:50:02 we can't for the others 14:50:05 in my opinion 14:50:11 well in theory you could make the items one repeatable 14:50:24 but the patron one not 14:50:42 indeed 14:50:45 note singular is a common convention in MARC, etc. but it may be repeatable. 14:50:49 we coudl say the others are wrong and stick with it 14:51:54 the more interesting are the other 4 14:52:39 quick hands up on note vs notes? 14:52:41 agreed 14:52:43 abstain 14:52:46 notes vs note I'm not that picky about 14:53:04 abstain 14:53:13 note at least if repeatable 14:53:33 guess it's tomas to pick then - tie breaker :) 14:53:41 it wont be repeatable.. json doesn't allow repeatable keys 14:54:03 Lets all fix that bug in json . 14:54:07 close_date = order_date? 14:54:22 if you want repeatable then it's `notes: [ note1, note2 ]` 14:54:42 ordered_date perhaps 14:54:49 again.. to add the tense 14:54:53 ordered_date++ 14:55:01 it#s interesteing 14:55:04 is the basket status ordered in the interanet? 14:55:06 I think it might be a german thing 14:55:08 when it is closed 14:55:11 for me sticking nouns together works :) 14:55:12 Project Koha_Master_D9 build #1082: SUCCESS in 45 min: https://jenkins.koha-community.org/job/Koha_Master_D9/1082/ 14:55:28 I tend to prefer ordering_date, but I guess it is because of my realtime spanish-english translation 14:55:33 Project Koha_Master_U18 build #553: UNSTABLE in 39 min: https://jenkins.koha-community.org/job/Koha_Master_U18/553/ 14:55:51 and that's why I raise this for peer review 14:55:51 he 14:55:55 i mean... we are famous for doing that - no critique, different perception 14:55:56 I hate english 14:56:08 lol 14:56:22 it's very much an 'eye of the beholder' language 14:56:25 learn german, you might love english more then :) 14:56:35 * ashimema speaks minimal german 14:56:38 but order is agreed on? 14:56:43 order* 14:56:44 cait, nope 14:56:46 ok 14:56:54 kohaputti: close? 14:57:09 I don't have latest master on my hands now but in the older version intranet states everywhere close basket, closed, etc. 14:57:17 no ordered date 14:57:19 kidclamp.. remind us exactly what closing a basket actually does 14:57:33 it changes the orderstatus from new to ordered 14:57:39 (not kidclamp... but) 14:57:48 English is very mailable, however, some things seem natural and others not, and there are conventions. 14:57:51 and only orders from closed baskets can be received 14:57:58 and can you still 'unclose' a basked.. and what does that do? 14:58:05 cait, ah, I think the countdown for missing items starts also on the time when basket is closed 14:58:06 it changes the status back 14:58:10 so ordered sounds good 14:58:16 hi all! 14:58:16 receivedremains received ,b ut orderd changes back to new 14:58:22 I think the issue we have here is that the code doesn't make much sense to start with :P 14:58:34 yes, i think it's also used for late orders 14:58:56 cait, yes, late orders is what I meant, there is the page where it shows if order has not arrived x days later from closing basket 14:59:07 koha assumes that it's when you are done entering the data and it's 'ordered' but it's a little muddy right now 14:59:12 so that would imply closing date is order date 14:59:31 there is an order date displayed in some places in koha 14:59:52 i know there are some bugs around that - we might want to work on that a bit, but from the workflow... it hink it would be correct 15:00:14 ok, up for vote? 15:00:20 some bugs argue you shoudl be able to edit the date - as you might have used the online portal - but that could be done stil 15:00:27 ordered_date avoids ambiguity about the time period referenced for the order such as not necessarily being the same as the date in which the vendor received or acknowledged the order. 15:01:09 ordered_date then? 15:01:13 yes 15:01:17 yes 15:01:21 (staying away from the voting tool for the small ones9 15:01:32 +1 15:01:41 ordered_date++ 15:01:42 authorised_by = basically i'd like to have _id whenever we are referring to some internal id 15:01:52 we do that in other tables as far as I could see 15:01:58 funds for example has an owner_id 15:02:05 of curse we have fund_id... borrower_id etc. 15:02:05 cait++ 15:02:09 oh patron_id sorry 15:02:19 this will come up again later in suggestions 15:02:35 managed_by = manager_id (one of the suggestions there) - but not sure what would fit here 15:02:45 hola amoyano_ 15:03:00 actually... maybe authorised is wrong and it should just be 'creator_id'? 15:03:05 how are we doing embeds here tcohen 15:03:16 what do you mean, ashimema? 15:03:21 authorised_by 15:03:33 I haven't got there, ashimema 15:03:36 but I wrote 15:03:46 to.. if you embed the linked patron how does the final object look 15:04:20 Yes, if the value is not authorised to authorise, then the person should not be identified as authorising. 15:04:21 the only one I wrote 15:04:34 is suggestion.suggestor 15:04:36 do we have both `authorised_by_id` and `authorised_by` fields present 15:04:40 which holds a patron object 15:04:49 or do we manipulate `authorised_by` so it's either an id or an object 15:04:49 we do, yes 15:04:56 we have both 15:05:46 * ashimema can't remember how he did it in rl.. but again so long as we're consistent 15:06:50 so.. if we're not mutating the key then we should have authorised_by_id slot for the id and authorised_by (or perhaps authorised_by_user) slot for the embed 15:06:57 does that make sense.. 15:07:16 from a JS developers side.. do you have an opinion there amoyano_ 15:07:16 it shows as 'created by' int he gui 15:08:02 aren't create and authorise distinct steps.. 15:08:09 I prefer creator: { patron_id: ... } 15:08:12 grr.. there's no created_by field. 15:08:20 I believe that if the keys are the same, the one with embeds should replace the other 15:09:25 but the name really depends on the "sub" that gets the embedded object in Koha::Object 15:09:27 amoyano_ they are not exactly the same (creator_id, creator) 15:09:36 so you would say "without embed = { authorised_by : 1 }" vs "with embed = { authorised_by : { patron_id : 1, name : "humpty dumpty" ... }" 15:09:52 If only an authorised person can create the basket / order then creator is much clearer. 15:10:09 s/creator/creator_id/ 15:10:23 tcohen in that case we will have both 15:12:01 #info Owen Leonard, Athens County Public Libraries, USA 15:12:04 ok 15:12:12 okies.. both is find and good 15:12:13 [off] Better late than never? 15:12:22 in which case.. I would add _id to the one's that are id's 15:12:25 not sure in case of this meeting ;) 15:12:51 and worry about the key of the embedded object later ;) 15:13:19 ashimema: we are trying to be consistent on that front 15:13:23 * amoyano_ agrees 15:13:36 and.. as for created vs authorised I would say it's history that's confusing us.. 15:14:51