June 2025 - Koha-bugs - lists.koha-community.org

[Bug 37905] New: Correctly fix the "last hour" filter on the job list
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '25

29 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37905 Bug ID: 37905 Summary: Correctly fix the "last hour" filter on the job list Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com See bug 36217 for more info, and especially the last comments. We want to revert what has been pushed and fix it properly with 2 lines of JS. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 34

[Bug 37888] New: Default filtering of background jobs could be improved
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '25

29 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37888 Bug ID: 37888 Summary: Default filtering of background jobs could be improved Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com >From Julian: I don't like the two available filters and the fact that they are enabled by default. 99% of the time I see an empty table because the jobs I just launched are already finished by the time I go to this page or because the job I want to check was queued more than an hour ago. Why don't we display the last X queued jobs by default ? I don't want to see unfinished jobs or "queued less than an hour ago" jobs. I want to see the more recent jobs. An option to filter out finished jobs is useful but in my case it would be less annoying if it was disabled by default. However, the 1 hour filter is arbitrary (why 1 hour ?) and not so useful in my opinion, as long as we can sort by queued date/time -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 36527] New: Patron category or item type not changing when editing another circulation rule
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '25

29 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36527 Bug ID: 36527 Summary: Patron category or item type not changing when editing another circulation rule Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com This was reported to me as a slightly different problem, but I was able to recreate it partially in master. When editing circulation rules, if you click on "Edit" on another rule and confirm you want to change that rule, the patron category and item type don't always change to the new one. To recreate: 1. Go to Administration > Circulation and fine rules 2. Add a couple of rules with various patron category/item type combinations 3. Click on "Edit" next to one of the rules --> The line should become highlighted in yellow and the values should be copied in the very last row 4. Click on "Edit" next to another rule 5. Click OK in the browser dialog box to confirm you want to edit another rule --> Depending on the rules, the values for the patron category and/or item type might not change in the editing row 6. Repeat steps 4 and 5 --> The patron category and item type do not always change I'm using Chrome with 23.12.00.015 on KTD (it does the same on my local master and my local 23.05.05 too). The person who reported it to me has 23.05.01. And their problem is that even on the first click (step 3), the values in the edit row are not the correct ones. The patron category stays "All" (the default value in the edit row), and the item type changes to the correct item type. I thought it could be a cache problem, but with KTD I assumed that was all included and taken care of. We also restarted plack and memcache on the client's install and the problem remains. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 36096] New: Add ability to select default sort and display length for tables on waitingreserves.pl
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '25

29 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36096 Bug ID: 36096 Summary: Add ability to select default sort and display length for tables on waitingreserves.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com There are 3 tables on waitingreserves.pl. ( holdscr | holdso | holdst ) It would be nice if we could set the default sort and display length via Table settings. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 36592] New: Cannot save Default display length or Default sort order in Table settings
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '25

29 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36592 Bug ID: 36592 Summary: Cannot save Default display length or Default sort order in Table settings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To recreate: 1. Go to Admin > Table settings 2. Find a table that includes Default display length or Default sort order. 3. Try to save a new value. 4. When the page reloads the new values have not been saved. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 39368] New: Warnings from t::lib::Mocks::Zebra because of statement after exec
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '25

29 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39368 Bug ID: 39368 Summary: Warnings from t::lib::Mocks::Zebra because of statement after exec Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Test Suite Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org # Previous test 1217 'POD coverage for t/lib/Mocks/Logger.pm' # Statement unlikely to be reached at /kohadevbox/koha/t/lib/Mocks/Zebra.pm line 119. # at /kohadevbox/koha/t/lib/Mocks/Zebra.pm line 119. # require t/lib/Mocks/Zebra.pm called at (eval 4894) line 1 # eval ' require t::lib::Mocks::Zebra ' called at /usr/share/perl5/Pod/Coverage.pm line 308 # Pod::Coverage::_get_syms(Pod::Coverage=HASH(0x569d3a0bbf50), "t::lib::Mocks::Zebra") called at /usr/share/perl5/Pod/Coverage.pm line 152 # Pod::Coverage::coverage(Pod::Coverage=HASH(0x569d3a0bbf50)) called at /usr/share/perl5/Pod/Coverage.pm line 209 # Pod::Coverage::naked(Pod::Coverage=HASH(0x569d3a0bbf50)) called at xt/author/pod_coverage.t line 40 # main::check_pod_coverage("t/lib/Mocks/Zebra.pm") called at xt/author/pod_coverage.t line 30 exec will replace the current process, it does not make sense to have another statement after. -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 39325] New: Run codespell successfully on the whole codebase
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '25

29 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39325 Bug ID: 39325 Summary: Run codespell successfully on the whole codebase Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 39324 Codespell is run by the QA script, but we have a lot of typos. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39324 [Bug 39324] [OMNIBUS] All QA tests should pass -- You are receiving this mail because: You are watching all bug changes.

1 101

[Bug 39705] New: Write POD when missing
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '25

29 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39705 Bug ID: 39705 Summary: Write POD when missing Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Bug 39367 added a POD entry to all subroutines: "Missing POD for" We should write correct documentation for those subroutines, maybe using AI? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 39367] New: Add POD to all subroutines/methods
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '25

29 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39367 Bug ID: 39367 Summary: Add POD to all subroutines/methods Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 39319 Blocks: 39324 In order to have a POD coverage test we need a starting point where all subroutines and methods will have a POD entry, even if empty. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39319 [Bug 39319] xt/author/podcorrectness.t only test POD for perl files within C4 and Koha https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39324 [Bug 39324] [OMNIBUS] All QA tests should pass -- You are receiving this mail because: You are watching all bug changes.

1 43

[Bug 39700] New: Fix test case t/db_dependent/Authority/Merge.t broken in 34739
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '25

29 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39700 Bug ID: 39700 Summary: Fix test case t/db_dependent/Authority/Merge.t broken in 34739 Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: domm(a)plix.at QA Contact: testopia(a)bugs.koha-community.org Bug 34739 adds some new tests to t/db_dependent/Authority/Merge.t, which work when run alone. But when running the whole test suite, some weird fails show up. This patch fixes that bug in the test suite The new test case calls AddBiblio. And AddBiblio returns ($biblionumber, $biblioitemnumber). But the test calls it like this: my $biblionumber = AddBiblio; AddBiblio returns a list, but the calling code only stores a single value, so it get's the last value, i.e. the biblioitemnumber. Now, when running the test alone, the DB sequences for biblio and biblioitem are in sync and both return the same value so the test works (by accident) But some tests add biblios with multiple items (or biblios without items), thus the sequences are no longer in sync and when the test tries to load a biblio via a biblioitemid, it finds nothing, which causes the fail bad: my $biblionumber = AddBiblio( $biblio_record, '', { skip_record_index => 1 } ); ok-ish: my ($biblionumber) = AddBiblio( $biblio_record, '', { skip_record_index => 1 } ); -- You are receiving this mail because: You are watching all bug changes.

1 11