← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
Time | Nick | Message |
---|---|---|
01:09 | khall joined #koha | |
04:32 | magnuse joined #koha | |
07:37 | reiveune joined #koha | |
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 | https://meetings.koha-community.org/2024/ | |
07:43 | development_irc_meeting_13_december_2023.2024-01-03-13.01.txt | |
07:44 | no idea what happened, but definitely something wrong | |
07:56 | cait joined #koha | |
08:00 | cait1 joined #koha | |
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 | did we get it wrong again? (minutes?) | |
08:33 | Joubu | I guess so |
08:34 | "13:01 #startmeeting Development IRC meeting 13 December 2023" | |
08:34 | https://irc.koha-community.org[…]4-01-03#i_2529472 | |
08:34 | 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 | I can do the wiki page edits manually I guess, but could you add it to the calendar? | |
08:39 | or can we cheat a meeting for Janaury so you can run the script? | |
08:39 | and I'll correct the minutes manually | |
08:40 | 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 | #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 | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
08:45 | 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 | #info Next meeting: 24 January 2024, 13 UTC | |
08:46 | #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 | Minutes: https://meetings.koha-communit[…]-01-16-08.45.html | |
08:46 | Minutes (text): https://meetings.koha-communit[…]4-01-16-08.45.txt | |
08:46 | Log: https://meetings.koha-communit[…]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 | 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 | 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 | Joubu: the next irc meetings didn't update | |
09:12 | should I update it manually? | |
09:12 | https://wiki.koha-community.or[…]Next_IRC_meetings | |
09:13 | I'll just do it | |
09:23 | done! | |
09:57 | ashimema | datetimes are still such a mess in Koha.. we really need to clearly document our expectations |
09:57 | 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.or[…]_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 | 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 | 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:42 | magnuse joined #koha | |
10:51 | cait | hm I don't like this line |
10:51 | + $("#table_search_selections").show().find("span").text(_("Patrons selected: " + number)); | |
10:51 | it needs to be double underscore because .js file | |
10:51 | but... shouldn't it be | |
10:52 | + $("#table_search_selections").show().find("span").text(_("Patrons selected: ) +" " + number); ? | |
10:52 | 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 | some other thing we shoudl document nicely somewhere | |
10:54 | :) | |
10:56 | I'll fix and test it | |
10:58 | $("#table_search_selections").show().find("span").text(__("Patrons selected: %s".format(number))); | |
11:11 | pushed... let's cross fingers :) | |
11:22 | oleonard joined #koha | |
11:27 | davewood | did something change regarding background workers in Koha 24.11? ... |
11:27 | 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 | /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 | 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:45 | cait1 joined #koha | |
11:48 | tcohen | ashimema, Joubu: git grep "\'NOW()" |
11:48 | we use it in many placed for datetime fields | |
11:48 | ashimema | I know we have a bunch of cases of it |
11:48 | but I also believe they're a problem | |
11:49 | we do a tonne of datetime horror in dt_from_string | |
11:49 | 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 | 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 | 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 | or are you saying we set it from koha-conf at connection time on top | |
11:51 | 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 | as I forget it every time I have to revisit it | |
11:52 | I had all sorts of issues in testing bookings because of this | |
11:52 | even noted it on the test plan | |
11:53 | if you test on a sandbox from canada for example.. it all gets royally screwed up | |
11:53 | because sandboxes are all set in a different timezone | |
11:53 | 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 | (since we introduced the TZ handling in Koha::Database | |
12:09 | ) | |
12:09 | ashimema | ok |
12:09 | 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 | https://git.koha-community.org[…]eUtils.pm#L64-L67 | |
12:11 | https://git.koha-community.org[…]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.or[…]_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 | 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 | readOnly doesn't quite work that way I think it should in our version of swagger | |
12:15 | the message pretty much looks the same as the others but with slightly different text | |
12:15 | 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-communi[…]=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 | 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 | 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.or[…]_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:44 | lds joined #koha | |
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 | bug 35277 | |
13:10 | huginn` | 04Bug https://bugs.koha-community.or[…]_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:35 | kidclamp joined #koha | |
13:37 | AnkeB joined #koha | |
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 | hm that's not good I guess | |
14:03 | @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 | should be | |
14:05 | -> __("Patrons selected: %s").format(number) | |
14:05 | cait | I tested it |
14:05 | and I coounted the parenthesis twice | |
14:06 | they all matched up | |
14:06 | tcohen | I did |
14:06 | cd koha-tmpl/intranet-tmpl/prog/js | |
14:06 | git grep '.format(' | |
14:07 | 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 | ok, I'll push a follow-up | |
14:09 | but it did work at least - I made sure to test :) | |
14:11 | $("#table_search_selections").show().find("span").text(__("Patrons selected: %s").format(number)); | |
14:12 | anyone working on thte test by chance? | |
14:12 | bug 35277 | |
14:12 | huginn` | 04Bug https://bugs.koha-community.or[…]_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 | hm they shoudl see it in git | |
14:17 | tcohen | ha, a race |
14:17 | aw-bib[m] | hi! https://koha-community.org/man[…]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 | the note seems not correct to me | |
14:19 | 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 | membership_expiry for an exampla | |
14:19 | 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 | 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 | that would make sense | |
14:21 | yes, documentation team uses bugzilla too | |
14:21 | 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 | brb | |
14:48 | back | |
14:54 | oleonard: around? | |
14:54 | oleonard | For a bit |
14:54 | cait | ah, and now it resolved itself |
14:54 | I was wondering about bug 35707 | |
14:54 | huginn` | 04Bug https://bugs.koha-community.or[…]_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.or[…]_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 | kidclamp++ | |
15:01 | # fixing the tests (I hope) testing now | |
16:00 | bag joined #koha | |
16:11 | reiveune | bye |
16:11 | reiveune left #koha | |
16:51 | cait | D12 turned green, hoping the same for the others |
16:55 | a good moment to stop for today - bye all! | |
17:00 | dpk__ joined #koha | |
17:01 | cait | regressions.t is failing randomly again *sigh* |
17:38 | cait joined #koha | |
18:43 | julieth joined #koha | |
18:47 | oleonard joined #koha | |
18:58 | dpk_ joined #koha | |
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/med[…]wbKXMeqIoSFkaIZjG>) |
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 | 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 | Have a nice evening | |
20:39 | EndemikDrake joined #koha | |
20:41 | FranciscoMartinez[m] joined #koha | |
20:51 | FranciscoMartinez[m] | Hi KOHA community,... (full message at <https://matrix.org/_matrix/med[…]EWALvZDVRbMAzeSgV>) |
20:55 | EndemikDrake | Hi! |
21:07 | davidnind | Francisco Martinez: There are two options you could take: |
21:08 | 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 | 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 | To answer some of the specific questions you asked: | |
21:12 | 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 | 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 | America) (apologies to anyone I have missed off/and got the coverage wrong!) | |
21:26 | .. 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 | 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 | 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 | 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 | yes, that would be a nice place to visit! | |
22:43 | cait | davidnind++ # all summed up very nicely! |
22:43 | I'd certainly try an update first | |
22:43 | our oldest database is 22.11 now and was started with a not yet released 3.2 | |
22:43 | it's certainly doable | |
22:44 | 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 | 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/2[…]abase-to-new.html | |
22:50 | davidnind | cait++ |
22:51 | Thanks cait for adding some great additional information! | |
23:00 | FranciscoMartinez[m] | Thanks Cait! Will look into it. |
← Previous day | Today | Next day → | Search | Index