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

[Bug 42476] New: Rephrase ElasticsearchEnableZebraQueue system preference
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42476 Bug ID: 42476 Summary: Rephrase ElasticsearchEnableZebraQueue system preference Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org The new system preference for reads: This preference should probably be set to 'Disable' unless you want Koha to act as a Z39.50 or SRU server. But this is not true, you can have Z39.50 and SRU without Zebra as well using the z3950-responder. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 40714] New: cookieConsent: current approach arguable on public computers or shared devices
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40714 Bug ID: 40714 Summary: cookieConsent: current approach arguable on public computers or shared devices Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Since we just save a simple key in localStorage, this may still be active on public computers for the next user of that computer? Unless they have separate guest accounts, or cookies and localStorage are cleared when the browser exits. Should we make a difference between browsing anonymous or logging in to Koha within this context of public computers? If so, we might need to save data in the db instead of locally? Looks like this report is less clear than the two others (40712 and 40713). -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 42853] New: OPAC self check-in does not resolve mis-routed transfers
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42853 Bug ID: 42853 Summary: OPAC self check-in does not resolve mis-routed transfers Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Blocks: 42851 Target Milestone: --- Split off from bug 42851. When an in-transit item is checked in via the OPAC self check-in (SCI) interface at a branch that is NOT the transfer's tobranch, the WrongTransfer message from AddReturn is ignored entirely (opac/sci/sci-main.pl:81 only reads $success). The original in-transit branchtransfers row is orphaned and shows forever on the "Transfers to receive" report. Proposed approach: - Same transfer resolution as the SIP2 case (bug 42851 child): complete the original transfer recording the actual location, open a new transfer from the check-in branch to the original tobranch, and re-link holds. - Additionally surface a screen message so the patron/staff route the item to the exceptions bin rather than the normal returns shelf. Test plan: 1. Transfer an item from A to B (in transit). 2. Check it in at branch C via OPAC self check-in. 3. Before: branchtransfers row A->B stays open forever, no message. 4. After: transfer resolved + new C->B transfer created, exceptions-bin message shown. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42851 [Bug 42851] [OMNIBUS] Items left stuck in transit when checked in outside the staff returns page -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 43167] New: Bug in C4::Ris::marc2ris: Destructive STDOUT closing breaks under Plack/PSGI (Error 500) and causes 0-byte exports when processing flawed MARC fields (e.g., 100 ind1 blank)
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43167 Bug ID: 43167 Summary: Bug in C4::Ris::marc2ris: Destructive STDOUT closing breaks under Plack/PSGI (Error 500) and causes 0-byte exports when processing flawed MARC fields (e.g., 100 ind1 blank) Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lopalejandro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- In KOHA 23.05.01 when exporting certain records to RIS format via OPAC or Intranet, the server throws an HTTP 500 Error. Plack error logs show: print() on closed filehandle STDOUT at opac-export.pl. This is triggered when the marc2ris function encounters a flawed MARC record—specifically, we isolated the trigger to MARC field 100 having a blank/empty Indicator 1, which breaks the author string evaluation. When this parsing fails, it triggers a cascade effect due to legacy code in /Koha/lib/C4/Ris.pm (sub marc2ris) that attempts to redirect STDOUT destructively: open my $oldout, qw{>}, "&STDOUT"; my $outvar; close STDOUT; open STDOUT,'>:encoding(utf8)', \$outvar; Under a Plack/PSGI environment, closing STDOUT destroys the HTTP output stream handle (_GEN_...), making it impossible to restore it at the end of the function. Any subsequent print call throws an HTTP 500. Furthermore, for analytic records lacking authors (like serials) where the output size doesn't exceed the memory buffer, skipping a proper STDOUT flush before the return causes the function to return an uninitialized variable, resulting in a 0-byte RIS file. Proposed Solution: Use local *STDOUT for a safe memory redirection, and close the localized handle strictly to flush the UTF-8 buffer before returning. Remove lines: open my $oldout, qw{>}, "&STDOUT"; # ... close STDOUT; open STDOUT,'>:encoding(utf8)', \$outvar; Replace with: local *STDOUT; open STDOUT,'>:encoding(utf8)', \$outvar; At the end of the function, remove the $oldout restoration and ensure the buffer is flushed: # close STDOUT; # open STDOUT, ">&", $oldout; Replace with: close STDOUT; # Flushes the buffer into $outvar return $outvar; -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 42929] New: Cannot add borrowers.primary_message_contact in the HOLD_SLIP
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42929 Bug ID: 42929 Summary: Cannot add borrowers.primary_message_contact in the HOLD_SLIP Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: marie-luce.laflamme(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- At the moment, Koha only displays borrowers.primary_message_contact in the hold confirmation popup which was introduced by this bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37860. However, this field is not available for use in the HOLD_SLIP template, making it impossible to print patron's preferred message contact method on the slip. It would be nice if borrowers.primary_message_contact could also be available in the hold slip template. This could be a small enhancement that would make the printed hold slip more consistent with the information already shown in the interface. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 43083] New: Simultaneous requests to CGI::Session overwrite each other's saved data, so changes can randomly disappear.
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43083 Bug ID: 43083 Summary: Simultaneous requests to CGI::Session overwrite each other's saved data, so changes can randomly disappear. Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: jacob.omara(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Every page request loads session and saves back when it finishes. I believe when two requests from the same user run at the same time, the slower one saves an old copy over the newer one. This was spotted in the browse results pane as sometimes the search was lost, causing it to no longer appear. It's possible this was due to busc being wiped intentionally by them visiting another opac page but I spotted it while investigating. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 41375] New: Tool to generate a default privacy policy document
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41375 Bug ID: 41375 Summary: Tool to generate a default privacy policy document Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org It would be nice to ship a default privacy policy document with Koha. It could be a configurable tool where superlibrarians could 1. check checkboxes for the types of data they are collecting in Koha 2. include the values of *Log system preferences 3. include templates from privacy regulations, such as GDPR, or national legislation (you could select which template to add) 4. define the durations of data collection (it would be nice to be able to read the triggers of cleanup-database.pl and other cronjobs, but this shouldn't be a blocker for this Bug) 5. document the use of cookies https://wiki.koha-community.org/wiki/Use_of_Cookies The tool would come with prewritten templates, but they should also be modifiable. Something like we currently have with notice templates. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 41756] New: RSS feed validation
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41756 Bug ID: 41756 Summary: RSS feed validation Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nicolas.hunstein(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When I perform a search in Koha, click on the RSS feed button, copy the generated string and then validate it on the page: https://www.rssboard.org/rss-validator/, I get the message: "It looks like this is a web page, not a feed. I looked for a feed associated with this page, but couldn't find one. Please enter the address of your feed to validate." Could this please be fixed? We suspect that there is a problem with the content type. -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 41722] New: Argument "" isn't numeric in numeric gt (>)... warnings in opac-detail.tt
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41722 Bug ID: 41722 Summary: Argument "" isn't numeric in numeric gt (>)... warnings in opac-detail.tt Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: roman.dolny(a)jezuici.pl QA Contact: testopia(a)bugs.koha-community.org The warning: [WARN] Argument "" isn't numeric in numeric gt (>) at /kohadevbox/koha/koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-detail.tt line 1578. appears in the plack-opac-error.log. It is quite strange because warning only appears when opac-detail.pl is used for very first time to show record. To reproduce: 1a. Use a fresh KTD or 1b. edit opac-detail.tt (save an insignificant change, like add a space) and restart plack. 2. Observe plack-opac-error.log. 3. Go to any bibliographic record with items in OPAC., e.g. search for "Perl template toolkit". ==> Warnings should appear in plack-opac-error.log ==> (as many as there are items). 4. Restart plack 5. Back to OPAC and refresh view of bibliographic record. ==> No warnings appear. 5. Repeat 1b., 4. and 5. ==> Warnings appear. It seems that check of existens "item_level_holds" is needed before using it in IF condition, but I can't find why warning appers in log only once, not every time when "item_level_holds" is checked in IF. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 40713] New: cookieConsent: key should have an expiration date
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40713 Bug ID: 40713 Summary: cookieConsent: key should have an expiration date Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Currently, the created localStorage key cookieConsent does not expire. This needs adjustment in view of following information: "The GDPR does not specify a fixed time limit for cookie expiry; instead, the duration must be proportionate to the cookie's purpose and never exceed 12 months according to the ePrivacy Directive, which requires consent renewal at least annually, and potentially more frequently based on your local Data Protection Authority's (DPA) guidelines, like the six-month recommendations from the Irish DPC and French CNIL." -- See e.g. https://gdpr.eu/cookies/ "If you use a cookie to store a record that a user has given consent to the use of cookies, you should ask the user to reaffirm their consent no longer than six months [*] after you have stored this consent state. (Footnote: While the legislation does not prescribe a specific lifespan for such cookies, based on a first-principles analysis by the DPC, we consider this to be the appropriate default outer timeframe for storing the user’s consent state. A controller would need to objectively and on a case-by-case basis justify storage for a longer period.)" -- Data Protection Commission [Ireland] Since localStorage has no expiration mechanism itself, we could simply add e.g. a unix timestamp as value here. Since the key now contains empty string and is tested for null to check status. This check would become: does the key exist and is its value still in future? A reject removes the key or clears it. Would it be possible to add the expiry period to a preference or enclosed in CookieConsentedJS somehow? -- You are receiving this mail because: You are watching all bug changes.

1 3