Time Nick Message
07:37 reiveune hello
07:43 Joubu cait: the meeting script is saying that there is no minute for the last dev meeting
07:43 Joubu https://meetings.koha-community.org/2024/
07:43 Joubu development_irc_meeting_13_december_2023.2024-01-03-13.01.txt
07:44 Joubu no idea what happened, but definitely something wrong
08:15 * cait1 waves
08:15 * cait waves again
08:15 cait I should be duplicating less now, new internet provider
08:29 Joubu seen my reply about the last meeting?
08:30 cait sorry, no
08:30 cait did we get it wrong again? (minutes?)
08:33 Joubu I guess so
08:34 Joubu "13:01 #startmeeting Development IRC meeting 13 December 2023"
08:34 Joubu https://irc.koha-community.org/koha/2024-01-03#i_2529472
08:34 Joubu yes...
08:37 cait can you give me a hint what was wrong? I am not seeing it
08:38 Joubu meeting was on Jan 3, #startmeeting is "13 December"
08:38 cait hm mus have copied the wrong wiki page and noone said anything
08:38 cait I can do the wiki page edits manually I guess, but could you add it to the calendar?
08:39 cait or can we cheat a meeting for Janaury so you can run the script?
08:39 cait and I'll correct the minutes manually
08:40 cait if I start and end meeting now with the correct data?
08:44 Joubu ok
08:45 cait ok, let's get this right
08:45 cait #startmeeting Development IRC meeting 3 January 2024
08:45 huginn` Meeting started Tue Jan 16 08:45:16 2024 UTC. The chair is cait. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:45 huginn` Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:45 huginn` The meeting name has been set to 'development_irc_meeting_3_january_2024'
08:45 cait This is to correct something for the meeting script. Nothing to read here.
08:46 cait #info Next meeting: 24 January 2024, 13 UTC
08:46 cait #endmeeting
08:46 huginn` Meeting ended Tue Jan 16 08:46:26 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
08:46 huginn` Minutes: https://meetings.koha-community.org/2024/development_irc_meeting_3_january_2024.2024-01-16-08.45.html
08:46 huginn` Minutes (text): https://meetings.koha-community.org/2024/development_irc_meeting_3_january_2024.2024-01-16-08.45.txt
08:46 huginn` Log: https://meetings.koha-community.org/2024/development_irc_meeting_3_january_2024.2024-01-16-08.45.log.html
08:46 cait I hope that worked
08:59 Joubu currently struggling with everything and I have locked my wiki account... reading mediawiki code trying to understand what I need to do to restore it...
08:59 cait ugh, ok, good luck
09:00 cait I'll try to update the Security release section a little bit with what you said in email and then move to pushing patches hopefully
09:01 cait let me know if I can help
09:06 Joubu cait: done!
09:07 cait Thank you, I'll fix the missing info in a moment
09:12 cait Joubu: the next irc meetings didn't update
09:12 cait should I update it manually?
09:12 cait https://wiki.koha-community.org/wiki/Next_IRC_meetings
09:13 cait I'll just do it
09:23 cait done!
09:57 ashimema datetimes are still such a mess in Koha.. we really need to clearly document our expectations
09:57 ashimema from db, through code, to api and ui etc...
09:57 cait documentation++ :)
09:58 ashimema tcohens seemingly innocuous and innocent change on bug 35788 highlights a lack of understanding all round
09:58 huginn` 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35788 enhancement, P5 - low, ---, jonathan.druart+koha, Signed Off , Remove Koha::Template::Plugin::Biblio::BookingsCount
09:58 ashimema you were right to push back there Joubu
09:58 ashimema though I agree with him at the same time that performance wise it would be nice to just be able to rely on the database.
10:00 cait I try to improve our docs as I am learning things right now... maybe just start small somwhere for the current issue you ran into?
10:01 cait everything is better than nothing :)
10:02 Joubu ashimema: we just need to use the same pattern everywhere. code-wise it's better to format_date from Perl (so that it's the same for 'now' and other dates), but for perf it's ofc better now()
10:03 ashimema yeah.. we need consistency in general
10:03 cait now() in SQL?
10:03 ashimema correct
10:03 cait was that a mysql thing or am I thinking about some other date function
10:03 ashimema now() in SQL is faster.. but due to our dt handling and munging it may not always be consistently correct with the assumptions we build
10:51 cait hm I don't like this line
10:51 cait + $("#table_search_selections").show().find("span").text(_("Patrons selected: " + number));
10:51 cait it needs to be double underscore because .js file
10:51 cait but... shouldn't it be
10:52 cait + $("#table_search_selections").show().find("span").text(_("Patrons selected: ) +" " + number); ?
10:52 cait we don't want the number bit in the parse for the translation, don't we
10:53 Joubu should be __("Patron selected: %s".format(number));
10:53 cait yeah, that looks better
10:54 cait some other thing we shoudl document nicely somewhere
10:54 cait :)
10:56 cait I'll fix and test it
10:58 cait $("#table_search_selections").show().find("span").text(__("Patrons selected: %s".format(number)));
11:11 cait pushed... let's cross fingers :)
11:27 davewood did something change regarding background workers in Koha 24.11? ...
11:27 davewood pgrep -flac 'perl /usr/share/koha/bin/background_jobs_worker\.pl.*--queue.*(default|long_tasks)$' returns 0 but if i want to start the workers i get "Error: worker already running for villanorth (default): failed!
11:33 davewood /usr/share/koha/bin/background_jobs_worker.pl moved to /usr/share/koha/bin/workers/background_jobs_worker.pl
11:40 cait you are in the future :)
11:40 cait but apart from that, I don't know, maybe someone else can help
11:45 tcohen hola #koha o/
11:45 oleonard Hi all
11:48 tcohen ashimema, Joubu: git grep "\'NOW()"
11:48 tcohen we use it in many placed for datetime fields
11:48 ashimema I know we have a bunch of cases of it
11:48 ashimema but I also believe they're a problem
11:49 ashimema we do a tonne of datetime horror in dt_from_string
11:49 ashimema to handle timezone and the koha-conf setting
11:49 oleonard datetime horror :D
11:49 ashimema I think we usually get away with it, because I think people rarely actually set it in the conf
11:49 ashimema but.. if you do set it and it differs from servertime or browsertime.. you'll find you get issues
11:50 tcohen I think the TZ in particular is covered
11:50 ashimema what I'm saying is we should set a standard and stick to it and code to fix all cases (including fixing dt_from_string and the api to get tz fixed)
11:50 ashimema no.. it's not
11:50 tcohen becasue we set the TZ at connection time
11:51 ashimema we also set it from the api using dt_from_string and the koha-conf setting
11:51 ashimema or are you saying we set it from koha-conf at connection time on top
11:51 ashimema maybe that does resolve it too
11:51 tcohen I'm all for consistency, though
11:52 ashimema I'd rather use 'NOW()' for performance if it's the case
11:52 tcohen if the caller is passing a date, it is clear some conversion needs to happen
11:52 ashimema we should document it.. again..
11:52 ashimema as I forget it every time I have to revisit it
11:52 ashimema I had all sorts of issues in testing bookings because of this
11:52 ashimema even noted it on the test plan
11:53 ashimema if you test on a sandbox from canada for example.. it all gets royally screwed up
11:53 ashimema because sandboxes are all set in a different timezone
11:53 ashimema and we don't handle it well
12:07 pastebot "tcohen" at 127.0.0.1 pasted "ashimema" (12 lines) at https://paste.koha-community.org/35611
12:08 tcohen I think you are correct when it i related to user input, but I always considered 'NOW()' safe
12:09 tcohen (since we introduced the TZ handling in Koha::Database
12:09 tcohen )
12:09 ashimema ok
12:09 ashimema lets document it and convert all current cases then 😜
12:09 tcohen yikes
12:10 ashimema we do a whole bunch of tz stuff in dt_from_string
12:10 ashimema https://git.koha-community.org/Koha-community/Koha/src/branch/master/Koha/DateUtils.pm#L64-L67
12:11 ashimema https://git.koha-community.org/Koha-community/Koha/src/branch/master/Koha/DateUtils.pm#L247
12:12 tcohen yeah, I know that code a bit. But most of it is dealing with making sure the 'user input' is converted to the right timezone, internally in the DateTime object
12:12 oleonard ashimema: I'm trying to test bug 35813 and I'm getting a 400 error when trying to modify a booking. Do you know why that might be?
12:12 huginn` 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35813 enhancement, P5 - low, ---, martin.renvoize, Needs Signoff , When placing a booking, we should feedback successful placements
12:12 ashimema whats the detail in the 400?
12:13 oleonard "Read only" path: body/booking_id
12:13 ashimema interesting
12:13 ashimema sounds like at some point we added readOnly into the api spec there
12:14 tcohen moving to the office at the northwest wing of the house, bbiab
12:14 ashimema and didn't fully test ☹️
12:14 ashimema readOnly doesn't quite work that way I think it should in our version of swagger
12:15 ashimema the message pretty much looks the same as the others but with slightly different text
12:15 ashimema I'll probably need to fix the readOnly thing on yet another bug
12:23 Annelisterman[m] What does this string mean in Batch patron modification? https://translate.koha-community.org/translate/koha/master/staff-prog/fi/?checksum=2970508be647bd38 The '%s' is replaced with the patron attribute that the user selects. For example if the selected patron attribute is "Color of hair" so the sentence wil be "This attribute will be only applied to the patron's category Color of hair".
12:29 Joubu Annelisterman[m]: Yes. If a patron's attribute is limited to a patron's category you will see this hint appears on the batch patron modification tool
12:30 Joubu so no. It will be "This attribute will be only applied to the patron's category Patron" if the attribute "Color of hair" is limited to the category "Patron".
12:33 Joubu right, it's not what it does. It's a bug.
12:42 Annelisterman[m] Yes, I assumed it would tell the patron category but it doesn't :D
12:44 Joubu Annelisterman[m]: fixed on bug 35817
12:44 huginn` 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35817 normal, P5 - low, ---, jonathan.druart+koha, Needs Signoff , Wrong hint on patron's category when batch update patron
12:44 Joubu thanks for catching that!
12:57 Annelisterman[m] Joubu: Great! :)
13:05 tcohen hola Joubu
13:06 cait can I get a quck fix for the test fail caused by 35277 please?
13:10 cait bug 35277
13:10 huginn` 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35277 normal, P5 - low, ---, nick, Pushed to master , Pseudonymization should be done in a background job
13:20 Joubu @later tell fridolin please backport 35759
13:20 huginn` Joubu: The operation succeeded.
13:59 tcohen cait: (at least) 22.11.13 has not been packaged, though it was released around Xmas
14:03 cait Joubu++ # rabbit bug hunting
14:03 cait hm that's not good I guess
14:03 cait @seen mtj
14:03 huginn` cait: mtj was last seen in #koha 3 weeks, 5 days, 13 hours, and 33 seconds ago: <mtj> ..will take a look at the openapi and pkgs stuff now
14:05 tcohen -> __("Patrons selected: %s".format(number))
14:05 tcohen should be
14:05 tcohen -> __("Patrons selected: %s").format(number)
14:05 cait I tested it
14:05 cait and I coounted the parenthesis twice
14:06 cait they all matched up
14:06 tcohen I did
14:06 tcohen cd koha-tmpl/intranet-tmpl/prog/js
14:06 tcohen git grep '.format('
14:07 tcohen because it looked suspicious
14:07 cait did you test?
14:08 tcohen .format is a valid String class method, so it will work
14:08 Joubu should be the same
14:08 tcohen it is just... different than what we do
14:08 Joubu but yes, tcohen is right
14:09 cait $("#table_search_selections").show().find("span").text(__("Patrons selected: %s".format(number)));
14:09 cait ok, I'll push a follow-up
14:09 cait but it did work at least - I made sure to test :)
14:11 cait $("#table_search_selections").show().find("span").text(__("Patrons selected: %s").format(number));
14:12 cait anyone working on thte test by chance?
14:12 cait bug 35277
14:12 huginn` 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35277 normal, P5 - low, ---, nick, Pushed to master , Pseudonymization should be done in a background job
14:13 cait I push the follow-up to the bug as well?
14:16 cait hm they shoudl see it in git
14:17 tcohen ha, a race
14:17 aw-bib[m] hi! https://koha-community.org/manual/latest/en/html/cron_jobs.html#notices states that processing of the message queue requires EnhancedMessagingPreferences set to allow. however if I get it right this only refers to advanced messages (iow everything beyond overdue notices), right? that is the script does not require said parameter. but who can configure what sends it depends on it. or do I miss understand here something?
14:17 tcohen should the test be adapted to only check that a task was scheduled instead?
14:18 cait aw-bib[m]: let me re-read that
14:19 cait the note seems not correct to me
14:19 cait in the manual
14:19 Joubu tcohen: yes, but then the tests must be moved to the background job tests
14:19 cait there are other notices/messages sent via the message_queue that are not part of enhanced messaging
14:19 cait membership_expiry for an exampla
14:19 cait enhanced messages are the checkboxes in the patron account
14:20 aw-bib[m] I understood that and this is why I wondered why I need the syspref to get the queue processed.
14:20 cait yeah, I think it's not correct
14:20 cait maybe that was supposed to go on the advanced_notices script
14:20 aw-bib[m] would I file some bug for that or how do you handle this kind of thing for docs?
14:21 cait one below
14:21 cait that would make sense
14:21 cait yes, documentation team uses bugzilla too
14:21 cait you can just file a bug for Documentation
14:21 aw-bib[m] ok, I'll give it a try.
14:33 cait looks good :)
14:33 cait brb
14:48 cait back
14:54 cait oleonard: around?
14:54 oleonard For a bit
14:54 cait ah, and now it resolved itself
14:54 cait I was wondering about bug 35707
14:54 huginn` 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35707 enhancement, P5 - low, ---, oleonard, Passed QA , Item statuses in the holdings table on biblio details should appear one per line
14:55 cait but it#s actually only one patch - so the alternate is the right one
14:55 Joubu cait, tcohen: bug 35819
14:55 huginn` 04Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35819 critical, P5 - low, ---, koha-bugs, NEW , "No job found" error for BatchUpdateBiblioHoldsQueue (race condition)
14:55 oleonard cait: Yes
14:58 cait Joubu++
15:00 cait kidclamp++
15:01 cait # fixing the tests (I hope) testing now
16:11 reiveune bye
16:51 cait D12 turned green, hoping the same for the others
16:55 cait a good moment to stop for today - bye all!
17:01 cait regressions.t is failing randomly again *sigh*
19:28 NikolayGospodinov[m] Hello. I have the following problem. After reindexing the zebra, when I search for a document in Koha it returns no result. This is the result from the reindexing the zebra: Records exported: 485445 12:04:13 [00:09:20]... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/HUPaDHlwbKXMeqIoSFkaIZjG>)
20:08 davidnind Nikolay Gospodinov: I'm not sure exactly how to resolve your issue - sometimes errors like this are to do with permissions. In a development environment I normally use (using the koha user) koha-rebuild-zebra -d -f -v instancename (I have not run a production environment). Reindexing using root can cause issues. Do the directories exist and do they have the "correct" permissions? That's about the limit of my knowledge...
20:09 davidnind Also it is quiet here around this time of the day, so posting to the general mailing list may be another way to get some help.
20:09 NikolayGospodinov[m] Okey. Thank you!
20:12 davidnind It is also helpful to say how you installed Koha (using packages is recommended) and the exact version of Koha you are using
20:15 NikolayGospodinov[m] I am using Koha 22.11.11. And I have replaced a database and reindexing zebra more than once. However, this time comes out with this problem.
20:17 davidnind Thanks - hopefully when someone reads back over the IRC log they may be able to offer a solution. It can be very frustrating when something works, then doesn't, when you are doing the exact same thing!
20:18 NikolayGospodinov[m] Yes
20:19 NikolayGospodinov[m] Have a nice evening
20:51 FranciscoMartinez[m] Hi KOHA community,... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/uHkgAqfEWALvZDVRbMAzeSgV>)
20:55 EndemikDrake Hi!
21:07 davidnind Francisco Martinez: There are two options you could take:
21:08 davidnind 1) Try an upgrade (setup a new server with a recent version of Koha (23.11.x is the latest, but many less risk-adverse libraries choose the version before as it can be more stable), use a database dump from your old system to test upgrading and resolving any errors that occur (there will probably be some!)
21:08 davidnind 2) Treat it has a migration: export your data (records, items, authority records, patron information, etc.), import into a fresh install of Koha (including configuring all the MARC bibliographic frameworks, library information, sytem preferences, and so on).
21:10 davidnind To answer some of the specific questions you asked:
21:12 davidnind Data compatibility: Your basic MARC data and patron information should be OK, but if you go with option 2 you would need to configure the new instance with your data (such as libraries, MARC framworks, patron categories, item types, and so on). It could also depend on whether the existing history is important, such as for statistics, etc.
21:13 davidnind Available resources: There are no easy to use guides or tools on the process, steps, all the things to look out for when upgrading, particularly for older versions. It is something I am working on, but it hasn't been high on my priority list lately.
21:17 FranciscoMartinez[m] Thank you for your answers, David!
21:22 davidnind Professional migration services: There are several support providers around the world that I am sure would love to help! See https://koha-community.org/support/paid-support/ Some of the active contributors to Koha, and who are active here in IRC, include ByWater Solutions (USA and further afield), PTFS Europe (UK and Europe), BibLibre (France), Equinox Open Library Initiative (USA), Catalyst IT (NZ/Australia/Europe), inLibro (Canada/North
21:22 davidnind America) (apologies to anyone I have missed off/and got the coverage wrong!)
21:26 davidnind .. also Theke Solutions (Tomás Cohen Arazi, Argentina, South America)
21:26 FranciscoMartinez[m] We are based in the Galapagos Islands, Ecuador
21:27 davidnind There are support providers in most continents (possibly the only one there isn't is Antartica 8-))
21:29 FranciscoMartinez[m] Thank you again for your time and expertise, David. Will try on our own as well to write a line to nearest providers.
21:32 davidnind Nice! I'm from New Zealand
21:34 davidnind Definitely chat to Theke Solutions (Tomás (tcohen) is active here on IRC, and was the release manager for the last two releases)
21:36 davidnind Many support providers don't restrict themselves to where they support Koha, but having a support provider familiar with your language and library requirements can be very helpful!
21:37 davidnind IRC can be quite at certain times (outside Europe and North America), so it can be useful posting to the Genrla Mailing List as well.
21:38 ashimema Galapagos islands, nice, bagsy that training of you picked us .
21:38 davidnind 🙂
21:38 ashimema Haha, in all seriousness, there's some great providers out there.. lots of knowledge and generally friendly and helpful
21:39 davidnind ...that should be Europe and North America timezones, and the General Mailing List!
21:39 davidnind yes, that would be a nice place to visit!
22:43 cait davidnind++ # all summed up very nicely!
22:43 cait I'd certainly try an update first
22:43 cait our oldest database is 22.11 now and was started with a not yet released 3.2
22:43 cait it's certainly doable
22:44 cait the database update takes care of rewriting the table structure and data structure for new versions - it's built into the update process
22:46 cait the most important bit is to import into an empty database in your update test installation - some good notes can be found here http://kohageek.blogspot.com/2015/08/move-old-koha-database-to-new.html
22:50 davidnind cait++
22:51 davidnind Thanks cait for adding some great additional information!
23:00 FranciscoMartinez[m] Thanks Cait! Will look into it.