14:01:22 <ashimema> #startmeeting Development IRC meeting 15 January 2020
14:01:22 <huginn`> 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 <huginn`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:22 <huginn`> The meeting name has been set to 'development_irc_meeting_15_january_2020'
14:01:31 <ashimema> #topic Introductions
14:01:47 <ashimema> #info Martin Renvoize, PTFS-Europe
14:01:58 <kohaputti> #info Joonas Kylmälä
14:02:06 <ashimema> #link https://wiki.koha-community.org/wiki/Development_IRC_meeting_15_January_2020 Agenda
14:02:20 <ashimema> 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 <tcohen> #info Tomas Cohen Arazi, Theke Solutions
14:03:48 <thd> #info Thomas Dukleth, Agogme, New York City
14:04:47 <cait> #info Katrin Fischer, BSZ, Germany
14:04:59 <cait> sorry, got distracted
14:05:10 <ashimema> shall we continue
14:05:20 <ashimema> #topic Announcements
14:05:27 <cait> yes please
14:05:32 <cait> I think people will drop in
14:05:37 <cait> ping qa_team
14:05:44 <cait> ping qa_team?
14:05:52 <cait> ping qa team?
14:06:09 <ashimema> rmaints?
14:06:09 <wahanui> hmmm... rmaints is talljoy, lucas, hayley
14:06:17 <ashimema> qa_teamp?
14:06:17 <magnuse> #info Magnus Enger, Libriotech, Norway
14:06:18 <ashimema> * qa_team?
14:06:21 <cait> qa team?
14:06:21 <wahanui> qa team are the real gatekeepers, send cookies their way
14:06:24 <kidclamp> #info Nick Clemens, ByWater Solutions
14:06:26 * cait gives up
14:06:46 <kidclamp> qa_team?
14:06:46 <wahanui> hmmm... qa_team is cait Joubu marcelr kohaputti josef_moravec tcohen kidclamp khall
14:06:51 <tcohen> Joubu id OFF
14:06:55 <cait> thx kidclamp :)
14:07:20 <ashimema> #info Marseile Hackfest20 - 23rd-27th March.. get your flights/trains/hotels booked and join us :)
14:07:40 <cait> lots to discuss today, so good to wake up some more people
14:08:05 <ashimema> #info Kohacon20 - Registrations are open, get yourself registered and start looking into visa applications
14:08:18 <ashimema> any other announcements I've missed?
14:09:01 <cait> #info There will be no Academy this year - feel free to grab any Academy bugs!
14:09:20 <ashimema> good one cait.. I forgot that
14:09:41 <koha-jenkins> Yippee, build fixed!
14:09:41 <wahanui> Congratulations!
14:09:41 <koha-jenkins> Project Koha_Master_D8 build #620: FIXED in 31 min: https://jenkins.koha-community.org/job/Koha_Master_D8/620/
14:10:03 <ashimema> #info Remember to use the `Mentored-by` line in your git commits if you'd like to help someone new :)
14:10:10 <tcohen> YAY
14:10:11 <ashimema> #topic Update from the Release manager
14:11:37 <ashimema> #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 <tcohen> \o/
14:12:42 <ashimema> #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 <kohaputti> thanks for focusing on the maintanance side for koha code, ashimema !
14:12:52 <ashimema> got team :)
14:13:51 <cait> go team :)
14:15:21 <ashimema> 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 <ashimema> so..
14:15:37 <ashimema> #topic Updates from the Release maintainers
14:15:38 <ashimema> rmaints?
14:15:39 <wahanui> rmaints is probably talljoy, lucas, hayley
14:15:47 <tcohen> is the dashboard up to date?
14:15:49 <cait> yes, the criticals need some work - also the old ones need checking so we get the number down again
14:15:56 <cait> tcohen: yes?
14:16:14 <koha-jenkins> 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 <ashimema> 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 <tcohen> ok, it felt like a cron routine didn't run, but only noticed on the patches submitted list
14:16:48 <tcohen> lets tackle the majors ASAP!
14:16:54 <ashimema> it's all live as far as I'm aware
14:16:55 <ashimema> no crons involved
14:17:31 <ashimema> #info Rmaints will be anouncing string freeze iminently for their respective branches
14:17:50 <ashimema> #topic Update from the QA team
14:17:54 <ashimema> cait :)
14:18:04 <cait> I know :)
14:18:43 <cait> #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 <cait> #info There is a lot of major bugs right now that auditing and fixing
14:19:12 <cait> ashimema: remind me of your keyword?
14:19:34 <cait> #info There is a keyword RM_priority that should help to select the more urgent ones
14:19:47 <ashimema> #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 <ashimema> keyword for what?
14:20:07 <cait> got it i think, RM_priority
14:20:26 <cait> anything else? kohaputti, kidclamp?
14:20:45 <ashimema> 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 <kidclamp> just working on ES bugs and fixes
14:20:53 <kohaputti> no, just huge shout out to Joubu for doing 28 passed qa already this month
14:20:59 <kidclamp> Joubu++
14:21:09 <cait> yep, Joubu++ :)
14:21:15 <tcohen> JOubu++
14:21:24 <cait> @karma JOubu
14:21:24 <huginn`> cait: Karma for "JOubu" has been increased 783 times and decreased 2 times for a total karma of 781.
14:21:34 <cait> not case sensitive it seems :)
14:21:35 <cait> moving on?
14:22:04 <ashimema> 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 <cait> that's a very good point
14:22:21 <ashimema> ok... moving on
14:22:35 <cait> also a lot of his is good stuff and fixes
14:22:35 <ashimema> #topic General development discussion (trends, ideas, ...)
14:22:49 <cait> shoudl we work from top to bottom?
14:23:08 <kohaputti> cait, sounds good to me
14:23:10 <ashimema> #chair cait
14:23:10 <huginn`> Current chairs: ashimema cait
14:23:22 <cait> ashimema: me?
14:23:23 <wahanui> it has been said that cait is really good at running into things
14:23:29 <ashimema> yup
14:23:37 <cait> oh yep... i have to sore spots as prove wahanui
14:23:52 <cait> ok, the first we are looking at is INVOICES
14:23:58 <cait> #link https://wiki.koha-community.org/wiki/Acquisitions_invoices_endpoint_RFC
14:24:02 <ashimema> lol
14:24:07 <cait> tcohen: can you explain the idea of close?
14:24:33 <tcohen> you mean closed
14:24:45 <cait> yes
14:24:48 <kohaputti> I assumed the close comes from the close_date value
14:24:55 <cait> there is no closed in the db
14:24:57 <kohaputti> i.e. whether it is defined or not
14:25:01 <tcohen> well, in the code and templates we usually check if closedate is set to something
14:25:03 <ashimema> yup
14:25:06 <tcohen> and render 'Closed'
14:25:29 <tcohen> in JavaScript it will be handy to just have a boolean with that calculated
14:25:43 <cait> so that would be an 'extra calculated value' that we expose?
14:25:43 <tcohen> so you write if (  invoice.closed ) { ... }
14:25:56 <tcohen> cait exactly, we do it in several places
14:25:57 <cait> and when you set 'closed' it will put in the current date?
14:26:08 <cait> POST I should say
14:26:40 <tcohen> right, there should be a route POST /.../invoices/:invoice_id/close { close_date: ... }
14:26:44 <tcohen> or similar
14:27:03 <cait> ok
14:27:04 <ashimema> is close_date readonly?
14:27:12 <tcohen> I haven't thought about that yet, I was focusing more on the mappings to get feedback
14:27:31 <cait> I think we will agree on shipping_cost_budget_id = shipping_cost_fund_id
14:27:32 <ashimema> and I agree.. we should use 'date_closed' to be clear of it's content I feel
14:27:39 <ashimema> past tense
14:27:41 <cait> close_date = date_closed - what is better semantically?
14:28:00 <cait> i see we mostly have date at the end, so withdrawin that suggestion
14:28:05 <cait> maybe closing_date?
14:28:06 <kohaputti> cait, you mean shipping_cost_budget_id => shipping_cost_fund_id ?
14:28:10 <kohaputti> cait, I agree with that
14:28:16 <thd> I might suggest closing_date .
14:28:18 <cait> sorry phone
14:28:29 <tcohen> I agree with thd
14:28:34 <ashimema> closing suggest future tense to me..
14:28:38 <thd> I meant even closed_date .
14:28:46 <ashimema> can it/shoult it be in the future
14:28:46 <khall> #info Kyle M Hall, ByWater Solutions
14:28:53 <thd> ... as opposed to close_date
14:29:21 <thd> ... close_date seems to be grammatically difficult to apprehend.
14:29:27 <ashimema> I bet we don't have a patturn for date params...
14:29:33 <cait> isn't closing the noun?
14:29:39 <ashimema> i.e date_* vs *_date
14:29:54 <thd> closing is also fine.
14:30:02 <koha-jenkins> 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 <thd> closing would be customary
14:30:19 <tcohen> closing would allow for future
14:30:19 <kohaputti> how have we put it in other end points / is there any with close/closing?
14:30:40 <cait> from what I see for consistency it shoudl be _date
14:30:47 <cait> but otherwise i think we don't have closing
14:30:50 <thd> If we use closing_date would be customary English.
14:30:57 <cait> we close subscriptions - but i woudl argue it's the wrong term there
14:31:13 <cait> it's more cancel/end
14:31:15 <ashimema> if we use `closing` then the `closed` boolean would need rethinking ;)
14:31:25 <cait> hm, no
14:31:26 * ashimema can't entirely remember how closed is used
14:31:29 <thd> ashimema++
14:31:30 <cait> because that is the status
14:31:31 <kohaputti> date_closed?
14:31:32 <cait> closed = 1
14:31:40 <cait> kohaputti: date at the end
14:31:43 <cait> :)
14:31:44 <ashimema> I meed the code that it uses cait
14:32:02 <cait> tcohen: which one do you want?
14:32:07 <ashimema> currently 'closed' = 'closedate contains anything, past, present or future'
14:32:12 <cait> i have a new idea actually
14:32:14 <cait> order_date
14:32:15 <kohaputti> we have shipping_date already there
14:32:15 <tcohen> I'm readnig the code
14:32:20 <cait> closing a basket switches the status to ordered
14:32:24 <ashimema> but a 'future' closing date should not set closed to true
14:32:24 <kohaputti> so closing_date would match with that
14:32:48 <cait> we are not very clear about that in all parts of the code, but a closed basket is ordered
14:33:05 <cait> an open basket is 'new' (unfinished, in progress)
14:33:17 <ashimema> we have a real mix of date vs date
14:33:37 <ashimema> even within endpoints... patrons for example has 'date_enrolled' and 'expiry_date'
14:33:42 <kohaputti> cait, we are discussing invoice here, not basket
14:33:54 <cait> kohaputti: agh, you are right
14:34:05 <cait> sorry, the phone call threw me off a little
14:34:09 <thd> 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 <tcohen> lately, I prefered putting the function before, as in suggestor_id, billing_date
14:35:30 <thd> tcohen++
14:35:30 * ashimema is happy either way around but likes consistency
14:35:31 <tcohen> but I don't have a strong opinion on this, I am all for consistency
14:35:56 <ashimema> so.. closed_date is fine by me..
14:35:57 <tcohen> and I reckon we can improve our naming consistency
14:36:19 <kohaputti> ashimema, but the other ones are future, like shipping_date
14:36:28 <ashimema> and I think it is 'closed' because I don't think we allow for closing an invoice in the future
14:36:32 <thd> Yes, if we develop or elicit principles, then we should apply them consistently including revisiting previous work.
14:37:18 <ashimema> 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 <ashimema> lol
14:37:21 <tcohen> thd if you volunteer to review existing endpoints, I can implement the changes
14:37:21 <cait> closed_date it is
14:37:38 <cait> do we have other things for invoices? move on?
14:37:43 * thd always volunteers.
14:38:10 <tcohen> thd will be looking forward to that
14:38:38 <thd> There is a principle contradiction.
14:38:40 <kohaputti> hmm, in the basket API RFC close_date was suggested
14:39:07 <tcohen> kohaputti: I did it very fast so I could get it reviewed
14:39:21 <thd> If we have some expectation of following the GUI, then either the API or the GUI needs changing ...
14:39:22 <tcohen> don't be strict on the original proposal, it is open for discussion
14:40:02 <cait> the GUI says close: i think
14:40:19 <cait> or closed... nm
14:40:21 <thd> ... Is shipping_cost_fund_id consistent with the GUI currently and not shipping_cost_fund_id?
14:40:30 <cait> yes
14:40:36 <cait> it's called shipping and fund
14:40:51 <cait> and id to be clear it requires an internal id
14:41:34 <cait> i know if we don't vote this, we will block tcohen's work
14:42:00 <cait> so could we agree on closed_date and *fund* ?
14:42:30 <kohaputti> I can agree, how to vote? :)
14:42:38 <ashimema> +1 from me
14:42:40 <cait> good question
14:42:44 <thd> 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 <tcohen> is someone updating the wiki?
14:43:09 <ashimema> I haven't updated the wiki yet
14:43:25 <cait> @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 <huginn`> cait: Error: No closing quotation
14:43:39 <cait> @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 <huginn`> cait: I suck
14:43:43 <cait> yes,...
14:43:47 <cait> help?
14:43:47 <wahanui> help is appreciated for bugs and keeping jenkins happy
14:44:06 <kohaputti> cait, try adding the quotes
14:44:12 <ashimema> #vote yes
14:44:20 <cait> found the mistake
14:44:24 <thd> #vote yes
14:44:27 <cait> @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 <huginn`> cait: I'll give you the answer as soon as RDA is ready
14:44:28 <wahanui> i already had it that way, huginn`.
14:44:30 <cait> #yes
14:44:34 <cait> #vote yes
14:44:37 <kohaputti> #vote yes
14:44:39 <tcohen> #vote yes
14:44:40 <cait> hm no
14:44:46 <ashimema> #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 <huginn`> 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 <huginn`> Vote using '#vote OPTION'. Only your last vote counts.
14:44:50 <cait> I am sorry everyone :(
14:44:51 <tcohen> #vote yes
14:44:53 <kohaputti> #vote yes
14:44:54 <ashimema> #vote yes
14:44:55 <cait> #vote yes
14:44:56 <tcohen> cait++
14:45:10 <cait> thx ashimema
14:45:12 <ashimema> sorry.. I ws mid looking up how it worked again
14:45:15 <cait> how hard can it be?
14:45:30 <ashimema> hehe
14:45:39 <cait> endvote?
14:45:46 <ashimema> #endvote
14:45:46 <huginn`> 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 <huginn`> yes (4): ashimema, cait, tcohen, kohaputti
14:45:50 <cait> next one
14:45:50 <wahanui> 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 <cait> BASKETS
14:45:58 <cait> #link https://wiki.koha-community.org/wiki/Acquisitions_baskets_endpoint_RFC
14:45:58 <kohaputti> wait
14:46:00 <kohaputti> invoices..
14:46:10 <kohaputti> what about discussing the readonly for closed_date?
14:46:31 <kohaputti> and the new endpoint for closing / opening the invoice
14:46:37 <tcohen> kohaputti I agree with having it read only
14:46:45 <tcohen> lets vote it
14:46:47 <cait> i think we only had the mapping so far - probably can be solved on the bug itself
14:46:55 <cait> tcohen: the readonly?
14:47:15 <cait> #startvote Shoudl we implement closed_date as readonly (yes, no, abstain)
14:47:15 <huginn`> Unable to parse vote topic and options.
14:47:17 <tcohen> I think I will refine the proposal with those details, lets vote the mappings
14:47:18 <kohaputti> I don't have an opinion on this, I would prefer to get some info on pros and cons
14:47:20 <cait> oh gah.
14:47:51 <cait> ok, so better hash that out on the bug .)
14:47:58 <cait> shoudl not stop development for now
14:48:03 <cait> baskets then?
14:48:05 <tcohen> FTR
14:48:07 <kohaputti> I'm up for leaving it to the developer
14:48:17 <cait> can you check on my comments on the wiki?
14:48:18 <tcohen> I'm working on the orders endpoint, which got pushed
14:48:34 <tcohen> I'm extending it so we can embed related objects on the response
14:48:40 <tcohen> that's why I need to have this mappings
14:48:51 <tcohen> I'm not jumping into developing those endpoints (yet)
14:49:07 <tcohen> I'm doing more barebones work
14:49:08 <ashimema> ok..lets just talk mappings for now
14:49:22 <ashimema> note vs notes..
14:49:37 <tcohen> notes
14:49:40 <cait> we got the notes on the others, so that's just a consistency one
14:49:49 <cait> close_date = order_date
14:49:55 <ashimema> 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 <cait> that was what i meant earlier...
14:50:02 <cait> we can't for the others
14:50:05 <ashimema> in my opinion
14:50:11 <cait> well in theory you could make the items one repeatable
14:50:24 <cait> but the patron one not
14:50:42 <ashimema> indeed
14:50:45 <thd> note singular is a common convention in MARC, etc. but it may be repeatable.
14:50:49 <cait> we coudl say the others are wrong and stick with it
14:51:54 <cait> the more interesting are the other 4
14:52:39 <cait> quick hands up on note vs notes?
14:52:41 <ashimema> agreed
14:52:43 <cait> abstain
14:52:46 <ashimema> notes vs note I'm not that picky about
14:53:04 <kohaputti> abstain
14:53:13 <thd> note at least if repeatable
14:53:33 <cait> guess it's tomas to pick then - tie breaker :)
14:53:41 <ashimema> it wont be repeatable.. json doesn't allow repeatable keys
14:54:03 <thd> Lets all fix that bug in json .
14:54:07 <cait> close_date = order_date?
14:54:22 <ashimema> if you want repeatable then it's `notes: [ note1, note2 ]`
14:54:42 <ashimema> ordered_date perhaps
14:54:49 <ashimema> again.. to add the tense
14:54:53 <tcohen> ordered_date++
14:55:01 <cait> it#s interesteing
14:55:04 <kohaputti> is the basket status ordered in the interanet?
14:55:06 <cait> I think it might be a german thing
14:55:08 <kohaputti> when it is closed
14:55:11 <cait> for me sticking nouns together works :)
14:55:12 <koha-jenkins> Project Koha_Master_D9 build #1082: SUCCESS in 45 min: https://jenkins.koha-community.org/job/Koha_Master_D9/1082/
14:55:28 <tcohen> I tend to prefer ordering_date, but I guess it is because of my realtime spanish-english translation
14:55:33 <koha-jenkins> Project Koha_Master_U18 build #553: UNSTABLE in 39 min: https://jenkins.koha-community.org/job/Koha_Master_U18/553/
14:55:51 <tcohen> and that's why I raise this for peer review
14:55:51 <tcohen> he
14:55:55 <cait> i mean... we are famous for doing that - no critique, different perception
14:55:56 <ashimema> I hate english
14:56:08 <cait> lol
14:56:22 <ashimema> it's very much an 'eye of the beholder' language
14:56:25 <cait> learn german, you might love english more then :)
14:56:35 * ashimema speaks minimal german
14:56:38 <cait> but order is agreed on?
14:56:43 <cait> order*
14:56:44 <kohaputti> cait, nope
14:56:46 <cait> ok
14:56:54 <cait> kohaputti: close?
14:57:09 <kohaputti> 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 <kohaputti> no ordered date
14:57:19 <ashimema> kidclamp.. remind us exactly what closing a basket actually does
14:57:33 <cait> it changes the orderstatus from new to ordered
14:57:39 <cait> (not kidclamp... but)
14:57:48 <thd> English is very mailable, however, some things seem natural and others not, and there are conventions.
14:57:51 <cait> and only orders from closed baskets can be received
14:57:58 <ashimema> and can you still  'unclose' a basked.. and what does that do?
14:58:05 <kohaputti> cait, ah, I think the countdown for missing items starts also on the time when basket is closed
14:58:06 <cait> it changes the status back
14:58:10 <kohaputti> so ordered sounds good
14:58:16 <caroline_catlady> hi all!
14:58:16 <cait> receivedremains received ,b ut orderd changes back to new
14:58:22 <ashimema> I think the issue we have here is that the code doesn't make much sense to start with :P
14:58:34 <cait> yes, i think it's also used for late orders
14:58:56 <kohaputti> 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 <cait> 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 <kohaputti> so that would imply closing date is order date
14:59:31 <cait> there is an order date displayed in some places in koha
14:59:52 <cait> 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 <kohaputti> ok, up for vote?
15:00:20 <cait> 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 <thd> 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 <cait> ordered_date then?
15:01:13 <cait> yes
15:01:17 <thd> yes
15:01:21 <cait> (staying away from the voting tool for the small ones9
15:01:32 <ashimema> +1
15:01:41 <amoyano_> ordered_date++
15:01:42 <cait> authorised_by = basically i'd like to have _id whenever we are referring to some internal id
15:01:52 <cait> we do that in other tables as far as I could see
15:01:58 <cait> funds for example has an owner_id
15:02:05 <cait> of curse we have fund_id... borrower_id etc.
15:02:05 <thd> cait++
15:02:09 <cait> oh patron_id sorry
15:02:19 <cait> this will come up again later in suggestions
15:02:35 <cait> managed_by = manager_id (one of the suggestions there) - but not sure what would fit here
15:02:45 <tcohen> hola amoyano_
15:03:00 <cait> actually... maybe authorised is wrong and it should just be 'creator_id'?
15:03:05 <ashimema> how are we doing embeds here tcohen
15:03:16 <tcohen> what do you mean, ashimema?
15:03:21 <ashimema> authorised_by
15:03:33 <tcohen> I haven't got there, ashimema
15:03:36 <tcohen> but I wrote
15:03:46 <ashimema> to.. if you embed the linked patron how does the final object look
15:04:20 <thd> Yes, if the value is not authorised to authorise, then the person should not be identified as authorising.
15:04:21 <tcohen> the only one I wrote
15:04:34 <tcohen> is suggestion.suggestor
15:04:36 <ashimema> do we have both `authorised_by_id` and `authorised_by` fields present
15:04:40 <tcohen> which holds a patron object
15:04:49 <ashimema> or do we manipulate `authorised_by` so it's either an id or an object
15:04:49 <tcohen> we do, yes
15:04:56 <tcohen> 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 <ashimema> 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 <ashimema> does that make sense..
15:07:16 <ashimema> from a JS developers side.. do you have an opinion there amoyano_
15:07:16 <cait> it shows as 'created by' int he gui
15:08:02 <ashimema> aren't create and authorise distinct steps..
15:08:09 <tcohen> I prefer creator: { patron_id: ... }
15:08:12 <ashimema> grr.. there's no created_by field.
15:08:20 <amoyano_> I believe that if the keys are the same, the one with embeds should replace the other
15:09:25 <amoyano_> but the name really depends on the "sub" that gets the embedded object in Koha::Object
15:09:27 <tcohen> amoyano_ they are not exactly the same (creator_id, creator)
15:09:36 <ashimema> so you would say "without embed = { authorised_by : 1 }" vs "with embed = { authorised_by : { patron_id : 1, name : "humpty dumpty" ... }"
15:09:52 <thd> If only an authorised person can create the basket / order then creator is much clearer.
15:10:09 <thd> s/creator/creator_id/
15:10:23 <amoyano_> tcohen in that case we will have both
15:12:01 <oleonard> #info Owen Leonard, Athens County Public Libraries, USA
15:12:04 <tcohen> ok
15:12:12 <ashimema> okies.. both is find and good
15:12:13 <oleonard> [off] Better late than never?
15:12:22 <ashimema> in which case.. I would add _id to the one's that are id's
15:12:25 <cait> not sure in case of this meeting ;)
15:12:51 <ashimema> and worry about the key of the embedded object later ;)
15:13:19 <tcohen> ashimema: we are trying to be consistent on that front
15:13:23 * amoyano_ agrees
15:13:36 <ashimema> and.. as for created vs authorised I would say it's history that's confusing us..
15:14:51 <ashimema> if the db field is 'authorisedby' but it actually contains whoever created the order and there's not a distinct authorisation step.. then I'd stick to 'created' in the api
15:14:58 <cait> I'd say it's historic yes
15:15:05 <cait> +1
15:15:31 <ashimema> that leaves the door open for future development if we ever want to allow for one person to create a basket and require a second person to authorize it and we want to record both values
15:15:39 <ashimema> why is acq so hard!
15:15:53 <cait> I dunno
15:15:54 * ashimema needs to fly off to get the kids
15:16:11 <cait> almost sorry for commenting ;)
15:16:34 <ashimema> can you take the lead for a few minutes cait.. just need to pop to the school and will try to join from my phone
15:16:41 <cait> i am not attached to the next too
15:16:54 <cait> billing_library
15:17:02 <tcohen> cait: it is the purpose, having you all comment on this
15:17:19 <thd> Acquisitions is difficult because too many things can and do go wrong in real world acquisitions which have been part of my job at various times.
15:17:24 <kohaputti> cait, the suggestion for billing_library is to replace it with invoicing_library?
15:17:35 <cait> an idea to discuss
15:17:40 <cait> realyl not sure about that one
15:17:53 <cait> the gui says delivery place and billing place - but this feature is not very clear in itself
15:18:06 <cait> it shows up on the basket group PDFs but not in another spot i can come up with right now
15:18:24 <cait> afaik there is no 'feature' for it apart from store and display
15:18:46 <cait> we do store branchcodes = library_ids
15:19:50 <tcohen> invoicing_library_id
15:19:53 <tcohen> should be
15:19:56 <cait> I think library is way better than 'place'
15:20:15 <cait> +1
15:20:29 <cait> hm or does it imply the library is invoicing?
15:20:33 <cait> ithink it's the one to get th einvoice
15:20:45 <kohaputti> here I think it means that the invoice is for the library to pay
15:20:53 <kohaputti> soo the vendor sends the invoice to that library
15:20:55 <cait> yes, to invoicing_library probably doesn't work
15:21:10 <kohaputti> that implies to me the library is sending an invoice
15:21:11 <cait> invoice_libarary_id? (love nouns :P)
15:21:23 <cait> oh yay, another native speaker ;)
15:21:28 <cait> btw oleonard: are you hiding? :)
15:21:30 <kohaputti> invoiced_library?
15:21:36 <cait> oooh
15:21:37 <cait> like that
15:21:42 <kohaputti> but that would also mean they might have already received the invoice?
15:21:45 <cait> invoiced_library_id? :)
15:21:48 * oleonard stays out of acquisitions arguments
15:22:01 <cait> oleonard: oh pleease :)
15:22:06 <thd> ordering_library might be closer to the function performed.
15:22:22 <kohaputti> thd, there is deliveryplace db column separately
15:22:52 <kohaputti> aaah, but that is already delivery_library
15:23:17 <kohaputti> so ordering_library_id sounds also good option
15:23:56 <kohaputti> any more suggestions?
15:24:03 <amoyano_> I like ordering_library_id
15:24:04 <thd> Is the value meant to hold an ID or a name?
15:24:43 <cait> it's the one to get the invoice
15:24:51 <cait> that can be different to the one ordering
15:25:02 <cait> delivery = gets the package
15:25:07 <thd> oh wow :)
15:25:11 <cait> billing = gets the invoice
15:25:15 <cait> order might be a central library
15:25:23 <cait> they coudl all 3 be different hings
15:25:32 <thd> Acquisitions is very difficult.
15:25:45 <cait> yes...
15:26:10 <cait> i htink thisis probably targetted at consortia
15:26:28 <kohaputti> who is the author for this endpoint?
15:26:32 <cait> tcohen:
15:26:36 <cait> all the acq
15:26:39 <cait> and suggestions
15:26:55 <kohaputti> tcohen, will the delivery_library have number id or the branchcode?
15:27:15 <cait> branchcode = library_id
15:27:16 <kohaputti> just clearing up this naming now with whether to have _id or not
15:27:19 <ashimema> Good question
15:27:28 <cait> branchcode is the prrimary key on branches
15:27:39 <ashimema> True
15:27:50 <kohaputti> ok, so branchcode would be the id in this case
15:27:54 <cait> and branchcode = library_id so far
15:27:59 <tcohen> branchcode  = library_id
15:28:07 <tcohen> in all the places
15:28:11 <thd> invoice_receiving_library or invoice_receiving_library_id seems to remove ambiguity.
15:28:28 <tcohen> _id should be there
15:28:33 <kohaputti> so we should definitely add the _id then here also if tcohen is planning to put the branchcode there as response
15:28:34 <cait> maybe billing is actually good
15:28:40 <cait> oh
15:28:41 <tcohen> so there's no ambiguity if we embed the actualy related object
15:28:43 <cait> invoiced_library_id
15:29:28 <kohaputti> cait, the problem with invoiced_library_id is that the invoice might have not been sent out yet.
15:29:46 <cait> i hate language
15:29:49 <kohaputti> though, maybe "invoiced library" has two meanings
15:29:59 <ashimema> Library_to_invoice
15:30:02 <cait> the one to be invoiced wit this...
15:30:04 <ashimema> Perhaps
15:30:40 <ashimema> The 'ing' kinda works here as it's tense agnostic
15:30:56 <ashimema> Invoicing_library
15:31:00 <cait> ashimema: you get the native speaker points
15:31:01 <tcohen> I need to feed Manuel, leaving this discussion in good hands
15:31:01 <thd> However, with enough parameters, there might be invoide_received (bool) to avoid improper implication of invoiced in past tense.
15:31:04 <tcohen> catch you later!
15:31:08 <ashimema> Me struggles to typed on phone
15:31:09 <cait> ashimema: but it's not the one issuign the invoice?
15:31:42 <cait> not sure how to continue here - shoudl we give it another go in 2 weeks?
15:31:50 <cait> and everyone comments on the things before?
15:31:52 <kohaputti> invoice_library_id would be my choice if we go with delivery_library_id – just to be consistend
15:32:33 <ashimema> That works for me too kohaputti.. still tense agnostic
15:32:37 <ashimema> I like that
15:32:41 <thd> kohaputti++
15:32:56 <ashimema> Let's go with that
15:33:11 <kohaputti> +1
15:33:40 <amoyano_> invoice_library_id and in the wiki specify that it's "the library that receives the invoice"
15:34:02 <kohaputti> cait, are you updating wiki?
15:34:23 <cait> i'd rather have tcohen do it
15:34:46 <cait> my brain is not working so well today
15:35:07 <thd> I have slept for a change.
15:35:07 <cait> does wednesday in 2 weeks work?
15:35:14 <cait> same time?
15:35:22 <ashimema> I can update the wiki upon my return from the school gates
15:35:29 <cait> thx ashimema!
15:35:33 <ashimema> Yes for me
15:35:36 <cait> #action ashimema to update wiki pages
15:36:01 <cait> #info Running out of time - further endpoint discussion postponed to next meeting in 2 weeks time
15:36:19 <cait> #topic Set time of next meeting
15:36:58 <cait> #info Next meeting: 29 January 2020, 14 UTC
15:37:02 <cait> #endmeeting