Time Nick Message 03:03 dcook Only a few hours to wait to share cool news haha 04:57 TriveniChandriki[m] Good morning all 04:58 TriveniChandriki[m] Can we use koha notification - WhatsApp messaging instead of SMS service 05:34 cait @seen Frido 05:34 huginn cait: I have not seen Frido. 05:34 cait @seen fridolin 05:34 huginn cait: fridolin was last seen in #koha 21 hours, 17 minutes, and 52 seconds ago: <fridolin> super green ;) 05:34 * dcook_ waves to cait 05:34 cait @later tell fridolin please push bug 33966 - breaks reporting for all non-english users 05:34 huginn cait: The operation succeeded. 05:34 cait hi dcook 05:34 wahanui hi dcook are you around? 05:39 cait dcook: any opinion on the datatype for bug 34029? I'd really like to see it moving, it breaks imports of valid data 05:39 huginn 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34029 normal, P5 - low, ---, katrin.fischer, Needs Signoff , Import breaks when data exceeds size of mapped database columns 05:40 dcook cait: I haven't thought about it enough to get a good opinion yet :/ 05:40 dcook The only sticking point in my head might be in terms of preallocation of bytes based on data type 05:40 dcook But it might not be an issue 05:41 cait I am totally not an expert there - we did the move to longtext for lccn, so I copied that mostly 05:42 dcook Another thing to take into account could be indexing on different data types 05:42 dcook And I think overall text might take up more space 05:42 cait I just know varchar(255) won't do anymore, especially with RDA 05:42 dcook Yeah fair enough 05:42 cait 264 is repeatable and it can get to be a lot of data 05:43 cait we also had problems with illus/pages with manuscripts, where things often are very descrpitive 05:43 dcook At some point, we might want to rethink some of the relational columns anyway 05:45 dcook I do have database schema on the brain atm thanks to bug 34064 05:45 huginn 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34064 enhancement, P5 - low, ---, dcook, Needs Signoff , Compare kohastructure.sql against current database using database audit script 05:45 dcook Hoping that is a bit of a game changer... 05:46 dcook But yeah with bug 34029... not sure yet. 05:46 huginn 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34029 normal, P5 - low, ---, katrin.fischer, Needs Signoff , Import breaks when data exceeds size of mapped database columns 05:48 dcook Actually at a glance the index thing isn't a problem since we're already only indexing the first 191 characters of publishercode anyway 05:48 cait seems an odd choice with varchar 255, but maybe it was incresased sometime already 05:49 dcook the indexing thing? 05:49 dcook It had to do with the utf8mb4 change 05:49 cait ah 05:50 dcook Can't remember how 191 got picked specifically, but has to do with a bytes vs characters thing 05:50 dcook It's really only a problem for unique indexes I think 05:51 dcook I've had TEXT data types for URL fields, and I wanted to use unique indexes but couldn't in the end because of the truncation needed 05:51 dcook But for a regular index.. it should be fine 05:51 dcook And publishercode is the only indexed field on that bug 05:53 cait that's good I guess? 05:55 dcook Could be a bit of a ticking time bomb but good enough for now.. 06:16 dcook Man that database audit script I did is wild. I have so many differences... although some of them aren't that significant but still they represent a discrepancy 06:21 fridolin salut 06:21 dcook hola frido 06:22 cait hi frido 06:22 cait left you a note about bug 33966 - just came up on the mailing list 06:22 huginn 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33966 major, P5 - low, ---, koha-bugs, Pushed to master , "Update and run SQL" for non-English templates 06:22 * fridolin waves 06:22 fridolin ok i will look at it asap 06:23 cait thx! 06:55 ashimema morning 07:03 magnuse kia ora ashimema 07:21 cait too many caits 07:58 ashimema All the cait 08:06 klasalle[m] Hello! Very very new to Koha and was wondering if someone could tell me how the data is hosted. I need to be able to be able to have a coherent conversation with the data protection office about Koha and GDPR to move forward, so any help would be great 08:13 ashimema Do you have a support company you're using klasalle? 08:14 ashimema Koha has lots of options when it comes to GDPR.. some clientside, some serverside. 08:14 klasalle[m] not currently. I've looked at some but haven't decided on one or if we should get one. Probably want one 08:15 ashimema I see, so self hosted? 08:16 klasalle[m] We'd like to if possible. We're a charity and hope to save money on it if we can 08:16 ashimema the data will all be in the database and depending on the settings you set you can add more, keep existing, anonymize or entirely discard various parts of it at various times. 08:16 ashimema there's lots of friendly folk in here that would happily help I'm sure 08:17 klasalle[m] there seems to be a lot of community support which is really nice 08:17 klasalle[m] I just know the first question I'll be asked is where is the user data stored, cloud/servers, and if I can't answer it we cant use it 08:18 ashimema https://koha-community.org/manual/22.11/en/html/patronspreferences.html#privacy 08:18 ashimema that's a good start for the clientside settings around GDPR 08:18 ashimema well that entirely depends on where you decide to host it 08:19 ashimema you can use a local system easily enough.. it'll need a computer turned on all the time so act as the server.. you can run it on pretty low specs really. 08:19 MatthewBlenkinsop[m] o/ 08:20 klasalle[m] ashimema: I see! okay that makes more sense. Thank you for that. 08:20 ashimema or, there are lots of reputable hosting providers out there.. for our clients the main requirement is that it's in the same country 08:22 ashimema a small debian server is the best option.. for highest security you'd want to keep it in house and prevent firewall it from the outside world... alternatively, good hosting companies will generally come fairly secure by default. 08:23 ashimema where are you based? There are various regulations you can look for in different countries.. like in the UK we have ISO27009 and CyberEssentials certifications that can be used to judge the strength of a companies security 08:24 klasalle[m] ashimema: We're in Ireland. I can ask the IT guy, he'd probably be better suited helping with that 08:24 ashimema π 08:24 ashimema Interleaf is a partner of ours (we're PTFS Europe).. just in case you do decide to go the supported route 08:24 klasalle[m] Not to say I'm just the librarian, but it sounds officially over my headπ 08:25 ashimema https://www.interleaf.ie 08:25 klasalle[m] I know interleaf! my sister in law used to work there. I was looking at PTFS actually 08:25 ashimema I imagine they do some good options for charities 08:25 ashimema ah, cool 08:27 klasalle[m] You've been ridiculously helpful. Was feeling overwhelmed , but I officially have a path to get things sorted. 08:27 ashimema π 08:27 ashimema glad I could help 08:30 klasalle[m] ashimema: Thank you π₯° 08:39 cait1 ashimema++ :) 08:45 ashimema cait 08:45 ashimema cait1 08:45 ashimema or magnuse 08:45 ashimema bug 24239 08:45 huginn 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24239 enhancement, P5 - low, ---, magnus, Needs documenting , Let the ILL module set ad hoc hard due dates 08:46 ashimema where can you actually set the due date in ILL 08:46 ashimema I don't see any UI changes at all.. 08:46 ashimema is it assuming the backend does that all the time? 08:46 cait1 it#s a backend thing 08:46 cait1 and a database column 08:46 cait1 when the database column for due date is set, the circulation will use it 08:47 ashimema OK.. so it's entirely backend dependant 08:47 ashimema I see 08:47 ashimema thanks 08:47 cait1 well, the "how it gets set" is, the way from there is not 08:47 ashimema shame FreeForm wasn't updated 08:48 cait1 we don't use the circulation from the ILL module - we do a "received" step in the ILL module, the due date is entered there and the hold we placed set to waiting 08:48 cait1 so they can later check it out normaly at the circ desk when the patron comes to pick it up 08:49 cait1 it would be a good idea to update freeform 08:49 cait1 where does it live? 08:49 cait1 I could make an issue 08:49 Joubu https://github.com/PTFS-Europe/koha-ill-freeform/issues 08:49 cait1 hm shoudl we move that to Koha-community repos maybe? 08:50 cait1 just a thought, if it's the reference one 08:50 cait1 not sure if free form has a step for when the item arrives 08:50 Joubu yes, it should be part of ktd as well, I think we discussed that recently 08:50 PedroAmorim[m] FreeForm does not support it 08:51 PedroAmorim[m] but the test plan mentions FreeForm 08:51 cait1 yes, but only to create a request 08:51 cait1 then the due date is set with SQL 08:51 cait1 the key is "has due date been set int he db" 08:52 cait1 PedroAmorim[m]: so an issue woudl not make sense then I guess? 08:52 cait1 filing one I mean 08:52 ashimema yup 08:53 PedroAmorim[m] yeah, I've only now reading the test plan more attentively 08:53 ashimema no. 08:53 ashimema not the ptfs repos 08:53 ashimema there's a version in koha repos on gitlab 08:53 * cait1 is confused now 08:53 ashimema that's the definitive 08:54 cait1 all the documentation has the ptfs links https://wiki.koha-community.org/wiki/ILL_backends 08:54 ashimema ho 08:54 ashimema it's koha-ill-koha I was thinking of 08:54 ashimema I thought FreeForm has also moved to gitlab 08:54 ashimema my mistake 08:54 cait1 i've never instaleld koha-to-koha tbh 08:54 cait1 so not sure if it woudl fit in there 08:55 ashimema https://gitlab.com/koha-community/plugins 08:55 ashimema I can migrate it to koha repo's if people are happy for me to 08:55 ashimema I think the FreeForm one should be core 08:56 cait1 moving to core would be nice, would also allow us to fix some minor glitches 08:56 ashimema Pedro has lots of fun things to do with ILL this cycle π 08:57 ashimema hopefully we'll have a much cleaner more modern set of options soon 08:57 cait1 btw PedroAmorim[m] - read your PMs 11:26 cait1 @quote random 11:26 huginn cait1: Quote #224: "jcamins: QueryParser! The all-singing, all-dancing, all-parsing, and all-finding new query parser for the search rewrite!" (added by druthb at 05:13 PM, December 17, 2012) 11:28 ashimema LOL 11:32 cait1 @quote random 11:32 huginn cait1: Quote #235: "libsysguy: I feel like working on koha is like cooking at the fire station. First one to complain is the next one to cook." (added by wizzyrea at 07:55 PM, March 07, 2013) 12:32 cait1 @quote random 12:32 huginn cait1: Quote #283: "<ashimema> ... looks like 'rtfm' only works if you read it right. :P" (added by mtompset at 01:29 AM, November 01, 2013) 12:32 cait too quiet around here 12:39 marcelr o/ 12:45 marcelr hey Zwolle ? 12:47 artez_zwolle[m] Hello 14:20 cait oh, there are people 14:27 * cait waves 14:28 Joubu hi cait 14:29 cait hi Joubu :) just saying hi so I don't feel so lonely 14:29 cait ? 14:32 marcelr o/ 14:38 Joubu hi again cait! hi marcelr! 14:38 Joubu :D 14:39 cait hello 14:39 wahanui bidet, cait 15:06 reiveune bye 15:48 ashimema is it just me.. or do we seem to lookup the user in auth.pm an obscene amount of times.. 15:49 ashimema could we not just set it earlier in the script and share that object instead of refetching so many times? 16:02 magnuse ashimema: sounds like a good idea 16:02 magnuse gah, my worker-output.log is filling up with tons of this: [2023/06/20 17:59:33] [WARN] Frame not processed - malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "You must log in usin...") at /usr/share/koha/bin/background_jobs_worker.pl line 115. 16:03 magnuse i have a hunch i looked at it earlier, but can't remember what i figured out... 16:05 magnuse i thought maybe bug 32573 but that is fixed in 22.11.03, and this is 22.11.04 16:05 huginn 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32573 normal, P5 - low, ---, kyle, Pushed to oldoldstable , background_jobs_worker.pl should ACK a message before it forks and runs the job 16:15 magnuse when i try to view the background jobs in the staff client i get an error and this in plack-api-error.log: [2023/06/20 18:13:48] [WARN] OpenAPI >>> GET api/v1/jobs [{"message":"Expected object - got null.","path":"\/body\/0\/context"},{"message":"Expected object - got null.","path":"\/body\/1\/context"},{"message":"Expected object - got null.","path":"\/body\/2\/context"},... 16:32 cait which version? 16:32 wahanui rumour has it which version is thiis 16:32 cait I think I had filed that and it was fixed 16:33 magnuse looks like my $frame = $conn->receive_frame; my $body = $frame->body; is returning the string 'You must log in using CONNECT first' 16:33 cait bug 32745 16:33 huginn 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32745 normal, P5 - low, ---, jonathan.druart+koha, Pushed to stable , Jobs view breaks when there are jobs with context IS NULL 16:33 magnuse 22.11.04 16:33 cait 22.11.06 patched 16:34 cait have to run - cya tomorrow! 16:34 magnuse cait++ 16:38 magnuse that fixed the problem of viewing the jobs in the staff client, but not the logs filling with errors 16:50 magnuse oops, 500 error from https://git.koha-community.org/Koha-community/Koha 17:21 magnuse bug 34070 17:21 huginn 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34070 major, P5 - low, ---, koha-bugs, NEW , background_jobs_worker.pl fills logs when not connecting 23:18 dcook @later tell ashimema I'd have to look again but looking up the user many times in Auth.pm sounds familiar... 23:18 huginn dcook: The operation succeeded.