September 2026 - Koha-bugs - lists.koha-community.org

[Bug 43391] Add POD to all private subroutines/methods
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43391 --- Comment #16 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Tomás Cohen Arazi (tcohen) from comment #15) > (In reply to David Cook from comment #13) > > Hmm I don't know about this as a solution... surely we don't want to be > > adding POD for private functions? > > There's a way fr the POD checker library we use to skip internal methods... > Honestly, I'd ask an LLM to add meaningful POD... Didn't do it to avoid > discussions about it. No worries. I think initially I was blindsided by the change, and couldn't really think of examples of seeing is out in the wild in industry, but then I started thinking about it some more today... and often the most complexity for Koha code can be in these private/internal functions, so I think I was wrong, and I think it's probably a good idea to add POD for new private/internal subs and where possible to add it for existing ones if the QA tool flags it (but only if you understand what it's actually doing). I'd hoped to have a chat at the dev meeting tonight about it, but I think my body isn't quite up to the challenge this time, I'm afraid. My apologies! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39417] New: Allow for editing/deletion of default SUGGEST_STATUS authorized values
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39417 Bug ID: 39417 Summary: Allow for editing/deletion of default SUGGEST_STATUS authorized values Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: heather(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There are libraries who do not use the default SUGGEST_STATUS authorized values for indicating the status of a purchase suggestion in the staff interface/OPAC. For example, libraries would rather use terminology like "Declined" as opposed to "Rejected". While it is possible to add more authorized values to this auth value category, it would be nice if those default values could be Edited or Deleted by staff, if desired. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 43391] Add POD to all private subroutines/methods
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43391 --- Comment #15 from Tomás Cohen Arazi (tcohen) <tomascohen(a)gmail.com> --- (In reply to David Cook from comment #13) > Hmm I don't know about this as a solution... surely we don't want to be > adding POD for private functions? There's a way fr the POD checker library we use to skip internal methods... Honestly, I'd ask an LLM to add meaningful POD... Didn't do it to avoid discussions about it. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43394] DT - pagination is broken if pageLength is not an integer
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43394 --- Comment #4 from Pedro Amorim (ammopt) <pedro.amorim(a)openfifth.co.uk> --- Thanks everyone! Pushed to main for 26.11! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43394] DT - pagination is broken if pageLength is not an integer
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43394 Pedro Amorim (ammopt) <pedro.amorim(a)openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)| |26.11.00 released in| | Status|Passed QA |Pushed to main -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43354] New: ILL request table search returns a 500 error
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43354 Bug ID: 43354 Summary: ILL request table search returns a 500 error Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: nugged(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Depends on: 33544 Target Milestone: --- The global Search field above the ILL requests table returns a 500 error after the request detail fields were combined into one display column. Steps to reproduce: 1. Enable the ILLModule system preference. 2. Open a patron record. 3. Click "ILL requests history" in the menu on the left. 4. Enter any text in the Search field above the table. Expected result: The table is filtered without an error. Actual result: Koha displays a 500 Internal Server Error and the table does not refresh. Technical note: The combined Request details column has an empty DataTables data source and no related-object search mapping. Global search therefore generates a query for "me." instead of the ILL request extended attributes. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33544 [Bug 33544] Squash some ILL fields to alleviate request table overflow -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 43259] New: Add to group does not add to group
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43259 Bug ID: 43259 Summary: Add to group does not add to group Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Steps to reproduce: 1 - Create a basket 2 - Create a group basket. At this step or the process : /cgi-bin/koha/acqui/basketgroup.pl clicking on "Add to group" does not add the basket to the group It is broken since 25.11.00. In 24.11, in basketgroups.tt there was an array named "grouped", to which the row containing the chosen element was added. It was created using : grouped = $("#grouped").DataTable($.extend(true, {}, dataTablesDefaults, { and row was added using grouped.row.add( row ).draw(); On main : $("#grouped").kohaTable(dt_params); row is added the same way : grouped.row.add( row ).draw(); This results in a JS error : "Uncaught TypeError: grouped.row is not a function" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 43117] New: t/Form_MessagingPreferences.t does not use Test::NoWarnings
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43117 Bug ID: 43117 Summary: t/Form_MessagingPreferences.t does not use Test::NoWarnings Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 34776 Target Milestone: --- From commit 6cc683b518223479f0c427a8305071fbd9581b5e Bug 34776: Unit tests -use Test::NoWarnings; -use Test::More tests => 2; +use Test::More tests => 1; +use Test::MockModule; +#use Test::NoWarnings; Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34776 [Bug 34776] Patron messaging preferences are lost when an error occurs during new account creation -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 42993] New: Koha::Edifact::Transport should log transport failures via Koha::Logger
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42993 Bug ID: 42993 Summary: Koha::Edifact::Transport should log transport failures via Koha::Logger Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Koha::Edifact::Transport reports every transport failure (no transport configured, connect failure, directory-change failure, file-listing failure and per-file download/upload failure) with carp. Under misc/cronjobs/edi_cron.pl these go to STDERR, so on a normal cron run the messages are lost: EDI simply goes quiet with nothing in editrace.log to explain why. This routes those failures through Koha::Logger on the 'edi' interface (the same interface edi_cron.pl already uses) so they are recorded in the EDI log. The two ingest()-level data warnings (duplicate filename, unreadable file) are intentionally left as carp: one is asserted by the existing unit test and neither is a transport failure. No change to the transfer logic. Test plan: 1. prove t/db_dependent/Koha/Edifact/Transport.t 2. Point an EDI account at an unreachable transport and run misc/cronjobs/edi_cron.pl; confirm the failure is now written to the EDI log rather than only to STDERR. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 42924] New: Restore default MaxAge for CSRF token
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42924 Bug ID: 42924 Summary: Restore default MaxAge for CSRF token Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Bug 17110 lowered the default MaxAge for the CSRF token from 1 week to 8 hours, but that has led to increased usability problems for negligible security gains. I propose to restore the default which is closer to the per-session approach for CSRF tokens which tends to be the default in many web frameworks like Django. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15