14:07:23 #startmeeting Development IRC meeting 1 April 2020 14:07:23 Meeting started Wed Apr 1 14:07:23 2020 UTC. The chair is ashimema. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:07:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:07:23 The meeting name has been set to 'development_irc_meeting_1_april_2020' 14:08:02 #topic Introductions 14:08:10 please use #info to introduce yourselves 14:08:12 meetings are no longer displayed/created in the agenda? 14:08:21 #info Jonathan Druart 14:08:22 #info Martin Renvoize, PTFS Europe 14:08:24 #info Marcel de Rooy, Rijksmuseum, Netherlands 14:08:25 they should be 14:08:35 I don't see them 14:09:03 next ones are on 8th and 9th and not there either 14:09:31 #topic Announcements 14:09:33 qa_team? 14:09:33 well, qa_team is cait Joubu marcelr kohaputti josef_moravec tcohen kidclamp khall 14:09:37 welcome back wahanui 14:10:00 interesting.. I don't see them either 14:10:03 grr 14:10:23 I will check when running the script, maybe there is an error 14:10:31 thanks Joubu 14:10:40 #info Thomas Dukleth, Agogme, New York City [capital of bad viruses and hour long queues to see empty shelves] 14:11:00 #info Owen Leonard, Athens County Public Libraries, Ohio, USA 14:11:30 #link https://wiki.koha-community.org/wiki/Development_IRC_meeting_1_April_2020 14:11:35 it's empty 14:11:39 #info The virtual hackfest was a reasonable success.. lots of bugs pushed and a huge amount of movement in bugzilla. Thankyou to everyone who contributed and got involved. 14:11:49 https://wiki.koha-community.org/wiki/Development_IRC_meeting_1_April_2020 14:11:50 #info Nick Clemens, ByWaterSolutions 14:12:07 * ashimema is juggling meetings 14:12:13 #chair Joubu 14:12:13 Current chairs: Joubu ashimema 14:12:26 #chair cait 14:12:26 Current chairs: Joubu ashimema cait 14:12:28 :D 14:12:34 any other anouncements? 14:13:40 ok 14:13:47 #topic Update from the Release manager 14:15:39 #info We are moving into the bugfix and polishing stage of the cycle now. I will be going through the rel_20_05_target and rm_priority lists and tidying it up... I will make some exceptions, but generally we should not be focusing on cleaning up for the release, finding and fixing bugs and polishing enhancements and new features. 14:16:06 not = now ? 14:16:08 #topic Update from the Release maintainers 14:16:12 rmants? 14:16:13 s/not// :) 14:16:20 ack.. correct 14:16:23 * ashimema can't type 14:16:30 rmaints? 14:16:30 i think rmaints is talljoy, lucas, hayley 14:16:47 hi! 14:16:52 #info Kyle M Hall, ByWater Solutions 14:17:01 #info Joy Nelson Bywater Solutions 14:17:12 [off] the fun of watching a folio demo whilst hosting a koha meeting 14:17:12 #info Lucas Gass, ByWater Solutions 14:17:43 I am behind, but taking this week to catch up to all the things that Martin has been pushing to master 14:18:22 19.05.09 was released last week, everything going along smoothly 14:18:43 it's been fast and furious of late.. sorry you've got so much to catch up on rmaints ;) 14:19:15 #info Katrin Fischer, BSZ, Germany 14:19:17 lukeG1: not sure you saw my later 14:19:20 #info Joy is catching 19.11 up with master that the moment.. fast moving master. 14:19:22 in 19.05.09 there are 2 features 14:19:34 bug 24260 is part of the release notes 14:19:34 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24260 new feature, P5 - low, ---, lari.taskula, NEW , REST Self Registration 14:19:42 no idea how it goes there 14:19:48 #info releases went out last week and included 2 new features 14:20:00 no, one :) 14:20:05 hmm, me either 14:20:11 https://koha-community.org/koha-19-05-09-release/ 14:20:34 I think we should edit the wiki and the release notes md file 14:21:19 s/wiki/website 14:21:44 because it's not actually in? 14:21:50 revert or bug number typo? 14:23:25 lukeG1: could you double check? 14:23:32 moving on then 14:23:33 #topic Updates from the QA team 14:23:51 cait maybe? 14:23:55 yes, i will Joubu, thanks for pointing out 14:24:00 QA team update: QA team is great. 14:24:01 thanks Joubu 14:24:20 thinking 14:24:20 thinking is so much easier 14:24:25 I think we should highlight bug 22001 that has been pushed a couple of days ago 14:24:25 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22001 enhancement, P5 - low, ---, jonathan.druart, Pushed to master , RaiseError and PrintError flags must be set for tests 14:24:36 can you say smething about the consequences? 14:24:37 wahanui: Easier than what?? 14:24:37 oleonard: no idea 14:24:47 some problems poped up, and I fixed them 14:24:54 but maybe there are some left 14:25:25 I think we need to write something to koha-devel about it, that's a bit technical and tricky 14:25:31 but basically, we did things wrong 14:25:38 not the first time :) 14:25:45 shoudl we action you for the email? 14:25:46 now it's correct for tests, but as things were wrong, we did other things to balance 14:26:09 #action Joubu add an email to koha-devel about 22001 (RaiseError) 14:26:12 will do 14:26:31 something else? 14:26:57 i think just the usual - queue is full, please QA :) 14:27:14 the hackfest was a success i think in that - the SO are really down, so QA is up 14:27:18 I made it down to 10 yesterday, this morning it was up again 14:27:29 not sure what to do... 14:27:31 yeah, it does that, good and bad 14:27:32 another thing 14:27:40 shoudl we start looking for next Release team? 14:27:54 we got about 2 months now, so maybe a little early, but not very early 14:27:59 we elected you as RM already cait 14:28:00 we need more hands on QA if possible 14:28:12 I know what date it is! .) 14:28:33 We should certainly start promoting for the next team 14:29:00 #topic General development discussion 14:29:07 * oleonard posts the job on LinkedIn 14:29:15 #info We should start thinking about the next cycle and the next team 14:29:19 Please vote on my RFC? 14:29:30 https://wiki.koha-community.org/wiki/Advanced_editor_macros_endpoint_RFC 14:29:31 #action Martin will send out an email 14:29:50 oh good one 14:30:00 #info Nick has an RFC we need to look at 14:30:08 #link https://wiki.koha-community.org/wiki/Advanced_editor_macros_endpoint_RFC 14:30:18 the api naming looks good to me 14:30:24 for the paths better to ask tcohen maybe 14:30:28 or someone else .) 14:30:38 I like tcohen's suggestion at the bottom of the page 14:30:49 agreed 14:30:52 just spotted it as well 14:30:55 yes, I will adopt his path changes 14:31:01 I like tcohens path 14:31:14 maybe we could even vote then? 14:31:28 please! 14:32:06 fancy phrasing a vote question someone? 14:32:16 incl path of tcohen 14:32:32 +! 14:32:37 hola 14:32:37 hello, tcohen 14:32:48 I didn't know it was wednesday already :-/ 14:32:50 tcohen must haveh eard us 14:32:54 "Heretofore shall it henceforth and in perpetuity..." 14:33:11 Should we accept the advanced editor macros endpoint as proposed by kidclamp on the wiki with the path changes proposed by tcohen? 14:33:14 * tcohen has just seen a green symbol on my IRC client 14:33:35 #startvote "Do you agree with the RFC for advanced editor macros as wirtten on the wiki including suggested path change by tcohen? (yes,no,abstain) 14:33:35 Begin voting on: "Do you agree with the RFC for advanced editor macros as wirtten on the wiki including suggested path change by tcohen? Valid vote options are , yes, no, abstain, . 14:33:35 Vote using '#vote OPTION'. Only your last vote counts. 14:33:47 #vote yes 14:33:50 #vote yes 14:33:52 #vote yes 14:33:54 #vote yes 14:33:55 #vote yes 14:33:55 kidclamp: was already typing sorry, saw your suggestion too late 14:33:57 should we have created and updated dates i there? 14:33:58 #vote yes 14:34:03 #vote yes 14:34:06 we can add those later 14:34:09 #vote yes 14:34:15 ashimema: like a tiemstamp? 14:34:21 indeed 14:34:42 I don't know.. how much auditing of macros may need to take place ;) 14:34:46 just a question.. 14:34:48 #vote yes 14:35:11 file a bug and I will add in timestamps after initial bug is in 14:35:13 but could be a separate bug maybe? if there isn't one currently 14:35:25 yes 14:35:31 auditing_columns++ 14:35:34 agreed 14:35:40 ending vote! 14:35:42 3 14:35:42 2 14:35:45 1 14:35:49 #endvote 14:35:49 Voted on ""Do you agree with the RFC for advanced editor macros as wirtten on the wiki including suggested path change by tcohen?" Results are 14:35:49 yes (9): Joubu, cait, tallerjoy, oleonard, ashimema, marcelr, khall, tcohen, thd 14:35:52 there you go 14:35:55 please update the wiki :) 14:36:05 thanks 14:36:08 will do, thank you! 14:36:08 #action kidclamp to update wiki with changes, vote date etc. 14:36:38 any more general discussion points? 14:37:09 * oleonard would like to advertise Bug 25031 14:37:09 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25031 enhancement, P5 - low, ---, oleonard, Needs Signoff , Improve handling of multiple covers on the biblio detail page in the staff client 14:37:15 I think it's fun. Please test! 14:38:29 oleonard: Don't you think we should have a multiple sysprefs for cover images? 14:38:44 We do 14:38:59 the bug better accommodates covers when multiple preferences are enabled at once 14:38:59 really? 14:38:59 really is good to have josef_moravec back.. always get a boost from seeing a bunch of signoffs :) 14:39:02 some of them need extra parameters - probably not possible to wraup it all in one? 14:39:41 Why not add a new admin page "Cover images sources" 14:39:49 we should have one you mean? 14:40:04 My patch doesn't make any changes to the covers features, it merely changes the display if you have multiple cover sources enabled. 14:40:19 yes ok 14:40:37 tcohen: we have a pref tab - catalog enrichments or so 14:41:39 better display for mulitple is quite a long standing bug - thx for tackling it Owen :) 14:41:53 um oleonard 14:41:53 i guess oleonard is happy for ashimema to write the release script 14:42:35 If folks like it I will try to adapt some of those principles to search results & OPAC 14:42:49 :) 14:43:57 oleonard++ 14:44:20 * oleonard will accept karma if the patch works ;) 14:45:11 moving on... 14:45:11 nothing else? 14:45:16 #topic Review of coding guidelines 14:45:34 I don't think we have anything to discus this time :) 14:45:42 I have a question that might be relevant 14:45:51 fire away 14:46:12 I was going to ask cait but I'll throw it out to you all: Do we have established rules for how to add the use of a cookie other than documenting it? 14:46:25 Rules about how the cookie can/should be removed, for instance? 14:47:07 Privacy stuff? 14:47:10 not that I know of - for the GDPR group my work was mostly documentation 14:47:24 i think if the feature is not used/active - set no cookie 14:47:34 keep cookie duration to a sensible length for the feature 14:47:54 be more careful in OPAC than in staff? 14:47:58 and use localStorage when possible 14:48:21 Was just about to say: guidelines for when to prefer cookies over localstorage and vice versa 14:48:30 right 14:48:45 when localStorage possible, use it 14:48:52 I'd like to hear more about folks' preference for localstorage 14:48:57 ie. no need to get the info on the server 14:49:46 i am not sure if we need to document those as well... but possibly? 14:49:56 kind of the same 14:50:02 nope 14:50:10 the usage is not the same 14:50:13 depends on what you store 14:50:40 if it's client only, you do not need to use a cookie 14:50:48 Joubu why wouldn't we document localstorage just as we do cookies? 14:51:03 we can, but there is no privacy concerns 14:51:13 not sure about that 14:51:18 localStorage is not shared with the server 14:51:27 thats not all 14:51:45 it is stored, maybe people dont want that 14:51:56 then use sessionStorage 14:51:57 i am really not sure about procedures there 14:52:18 it's stored as well but removed when the tab is closed 14:52:44 I think our answer should be: Document localstorage just as we do cookies because more information is better. 14:54:17 none is used at the OPAC it seems 14:54:41 from Koha code (but used by emoji-picker) 14:55:06 really? 14:55:06 really is probably good to have josef_moravec back.. always get a boost from seeing a bunch of signoffs :) 14:55:16 koha-tmpl/opac-tmpl/lib/emoji-picker/js/util.js: localStorage.setItem(key, value); 14:55:21 oh! 14:55:21 wahanui: forget really 14:55:21 oleonard: I forgot really 14:55:54 did we use sessionStorage for searches ? 14:56:25 marcelr yes 14:56:35 In the staff client 14:56:49 is there some docs to read so I undestand the concern about cookies¿ 14:56:50 forget really 14:57:02 wahanui: forget really 14:57:02 cait, I didn't have anything matching really 14:57:08 oh :) 14:57:13 found that if you want, there is a table that explains clearly the differences https://wpreset.com/localstorage-sessionstorage-cookies-detailed-comparison/ 14:57:23 tcohen: I think it all stems from GDPR 14:57:25 like "Accessible server-side – yes no no" 14:57:50 interesting 14:58:00 cookies and localStorage are the only way to have persistent state browser-side 14:58:41 https://softwareengineering.stackexchange.com/questions/290566/is-localstorage-under-the-cookie-law (probably not best source) claims local storage is also eccected by cookies 14:59:00 eccected ? 14:59:22 hm does't seem like the original soruce of tha tstatement still exists, so probably need to do more research 14:59:27 sorry 15:00:12 well localstorage is also in the GDPR domain 15:00:12 okay, marcelr. 15:01:28 not against use - but we might be better off documenting 15:01:44 and from the beginning, because finding them al was no fun and I still feel i might have missed some 15:01:47 Okay: 1. Prefer localstorage if possible. 2. Document both cookies and localstorage. 15:01:59 Sound correct? 15:02:07 coudl someone try and phrase out an update to the coding guideline including this? 15:02:07 And hold back from adding them too much ? 15:02:08 prefer sessionstorage first 15:02:16 then local, then cookie 15:02:16 +1 15:02:24 then send me cookies 15:02:49 I'd like to suggest that we document new cookies/localstorage on the wiki when we submit patches, not just after they're pushed to master 15:03:02 It'd be good to catch that stuff during QA 15:03:12 add when they are pushed 15:03:40 whoever catches it - there is a cookie keyword that can be set 15:04:07 we could note 'in dev' for version and the bug number 15:05:49 * oleonard likes that 15:05:59 sessionStorage would be the option for those concerned about privacy, but using that instead of localStorage would be a big behaviour change 15:06:15 am I getting it right? 15:06:41 tcohen: We could switch to sessionStorage for any cookie which we set only for the session 15:07:52 we can at least define a goal - and use it for new features, move ove the others 15:08:53 example, bug 25027 I wrote yesterday, move from sessionStorage to localStorage 15:08:53 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25027 enhancement, P5 - low, ---, jonathan.druart, Needs Signoff , Result browser should not overload onclick event 15:09:25 (to see the difference between both) 15:09:32 Joubu++ 15:09:53 I think most of the time we need localStorage over sessionStorage 15:10:43 htg 15:11:24 The question came up for me in part because I was working on Bug 24625, which seems to be a great candidate for sessionStorage 15:11:24 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24625 enhancement, P5 - low, ---, oleonard, NEW , Phase out jquery.cookie.js: showLastPatron 15:12:35 sounds like it is, yes 15:12:41 Anyway, I think we needn't continue this discussion now since the meeting is running long now 15:13:05 you are rright 15:13:07 moving on? 15:13:18 #topic Set time of next meeting 15:13:24 thx Joubu 15:13:32 2 weeks? 15:13:48 15 April 2020, ? 15:13:49 hour? 15:14:13 #info Next meeting: 15 April 2020, 20 UTC 15:14:13 that? 15:14:13 it has been said that that is what blou added in his patch 15:14:23 20 UTC? 15:14:23 i heard 20 UTC was currently set for the general meeting but I think 19 UTC may be closer to what people favoured in the preferred times poll. 15:14:30 not sure how this works with recent daylight savings changes 15:14:39 wahanui you are full of comments today 15:14:39 ...but wahanui is back??!!!|a political leader|a conch... 15:14:46 i am wayyy too slow today :) 15:14:48 works for mw! 15:15:08 end? 15:15:09 #endmeeting