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

[Bug 38900] New: translation script explodes without meaningful error when "incorrect" structure is found
by bugzilla-daemon＠bugs.koha-community.org 01 Mar '26

01 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38900 Bug ID: 38900 Summary: translation script explodes without meaningful error when "incorrect" structure is found Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: I18N/L10N Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: f.demians(a)tamil.fr, jonathan.druart(a)gmail.com Found when working on bug 38714, the translation script can break with en error that does directly point to the problematic string [13:00:23] Error: Command failed: misc/translator/xgettext.pl --charset=UTF-8 -F -o /tmp/koha-2rwDEm/Koha-opac-bootstrap.pot -f /tmp/koha-2rwDEm/files Can't use an undefined value as a HASH reference at misc/translator/xgettext.pl line 131. at ChildProcess.exithandler (node:child_process:422:12) at ChildProcess.emit (node:events:517:28) at ChildProcess.emit (node:domain:552:15) at maybeClose (node:internal/child_process:1098:16) at ChildProcess._handle.onexit (node:internal/child_process:303:5) at Process.callbackTrampoline (node:internal/async_hooks:128:17) [13:00:23] 'po:update' errored after 992 ms -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 38773] New: SMTP server is not showing on the library detail page
by bugzilla-daemon＠bugs.koha-community.org 01 Mar '26

01 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38773 Bug ID: 38773 Summary: SMTP server is not showing on the library detail page Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When an SMTP server is selected for a library, it is well displayed in the form to modify the library and in the list of all libraries (in column SMTP server) but when viewing a library detail (without editing) the line "SMTP server" is empty. To reproduce : 1- Create an SMTP server in Koha (it doesn't need to be valid) a- Go to Administration > Additional parameters > SMTP servers b- Click on "New STP server" c- Fill all mandatory fields (it doesn't need to be valid information) d- Click on "Submit" 2- Add the created SMTP server to a library a- Go to Administration > Basic parameters > Libraries b- Choose a library and click on Edit (in column "Actions") c- On the line "SMTP server" select the server created d- Click on "Submit" 3- Check the display a- Go to Administration > Basic parameters > Libraries b- Check that the name of the SMTP server you just selected is displayed in the column SMTP server c- Click on the name of the library you modified d- Check that the line "SMTP server" is empty e- Click on "Edit library" f- Check that the name of the SMTP server you just selected is still selected -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 29

[Bug 38988] New: If JobsNotificationMethod is not STOMP the about page shows as if there was a problem
by bugzilla-daemon＠bugs.koha-community.org 01 Mar '26

01 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38988 Bug ID: 38988 Summary: If JobsNotificationMethod is not STOMP the about page shows as if there was a problem Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: About Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org I'm not sure how bug 35655 ended up doing this, but it is not ok: * If polling is selected, the `text-bg-warning` is picked, and in the STOMP case it is `text-bg-info`. Both are ok so should be displayed the same. * In the `System information` section, you end up with the message about not being able to connect to the message broker. Which is a feature if you chose `polling` so no error at all. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 40002] New: Cannot filter patrons by "Browse by last name"
by bugzilla-daemon＠bugs.koha-community.org 01 Mar '26

01 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40002 Bug ID: 40002 Summary: Cannot filter patrons by "Browse by last name" Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Staff interface Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 37334 Caused by commit e8129f5aeaa3ca11dcd62cccee0f171209dea605 Bug 37334: Allow a column filter to be shown even searchable is off Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37334 [Bug 37334] Cannot filter holdings table by status -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 41298] New: Filtering holdings table with status In transit considers every item ever transferred to be "In transit"
by bugzilla-daemon＠bugs.koha-community.org 01 Mar '26

01 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41298 Bug ID: 41298 Summary: Filtering holdings table with status In transit considers every item ever transferred to be "In transit" Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: anneli.osterman(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Bug 37334 reinstated to ability to filter holdings table with status. We noticed that filtering holdings table with status "In transit" shows every item that has been transferred even once. Meaning if there is even one row mentioning it's itemnumber in branchtransfers it is considered as "In transit". The transfers does not have to be currently active when it is considered "In transit". This also causes the "Available" status not to work properly because they are often considered as "In transit" (at least in our large consortium items transfer alot between branches and it is quite rare that item has never been transferred in it's lifetime) How to test: 1. Transfer item 1 from branch A to branch B 2. Receive/Fullfill the transfer in branch B - Item is now "Available" 3. Go to items record and filter holdings table with status In transit 4. Notice that item 1 is shown even when it is actually "Available" 5. Filter holdings table with status "Available" and notice that item 1 is not shown. I have tested this in version 25.05.03 and in Open Fifth's sandbox and it happens in both of them. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 39932] New: Koha::Item->_status should return an array
by bugzilla-daemon＠bugs.koha-community.org 01 Mar '26

01 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39932 Bug ID: 39932 Summary: Koha::Item->_status should return an array Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com The `_status` method has a couple problems: * It doesn't have a POD * It returns a string! It should return a list instead, so handling on the UI doesn't require splitting the string back. That said, the tests using it in the UI (Holdings_spec.ts) only test the `available` rendering use case. This is minor. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 39000] New: "Encoding errors" block on detail page hurt the eyes
by bugzilla-daemon＠bugs.koha-community.org 01 Mar '26

01 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39000 Bug ID: 39000 Summary: "Encoding errors" block on detail page hurt the eyes Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface 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 Depends on: 35402 https://snipboard.io/wUmV50.jpg Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35402 [Bug 35402] Update the OPAC and staff interface to Bootstrap 5 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 39346] New: Only 20 supplementary fields are usable in Agreements
by bugzilla-daemon＠bugs.koha-community.org 01 Mar '26

01 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39346 Bug ID: 39346 Summary: Only 20 supplementary fields are usable in Agreements Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com In administration, create 25 supplementary fields for ERM Agreements In ERM module, create an agreement : only 20 of the supplementary fields will be displayed It must be an issue with API call? Maybe it affects also other parts of Koha? If so it should be fixed everywhere -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 39180] New: Handle and report exception at checkout/checkin due to missing guarantor
by bugzilla-daemon＠bugs.koha-community.org 01 Mar '26

01 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39180 Bug ID: 39180 Summary: Handle and report exception at checkout/checkin due to missing guarantor Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When ChildNeedsGuarantor is enabled, Koha will throw an exception and fail to check an item in if the borrowing patron could have a guarantor but does not. The failed checkin gives a generic messages about configuration issues. We should check the item in and report on the screen that the patron should have a guarantor. To recreate: 1 - have a patron in a category that can be a guarantee but does not have a guarantor on their account 2 - set TrackLastPatronActivityTriggers to update the patron on checkin of an item 3 - check an item out to your patron 4 - set ChildNeedsGuarantor to "must have" 5 - check your item in, get error It also throws an exception at checkout if your tell TrackLastPatronActivityTriggers to update at checkout, but the checkout succeeds. We've seen inconsistent behavior between production and test sites around the specifics of this error that we haven't quite nailed down yet. It's possible something changed here between 24.05.06 and main as they generate this error slightly differently. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 36

[Bug 35826] New: Optimize building of holds queue based on transport cost matrix
by bugzilla-daemon＠bugs.koha-community.org 01 Mar '26

01 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35826 Bug ID: 35826 Summary: Optimize building of holds queue based on transport cost matrix Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andreas.jonsson(a)kreablo.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There are several problems when building the holds queue which makes it hard for the libraries to predict the outcome for how items are allocated based on their configured policy. 1. The allocation of items should be done by optimizing on transport cost. Currently a greedy algorithm is applied when building the holds queue which doesn't always produce optimal results. 2. The allocation of items should not fall back to some default allocation if an allocation by using the transport cost matrix fails. If no allocation can be found that satisfies the configured constraints it is a violation of the configured policies o proceed and make an allocation. 3. Although items at the local library have transport cost 0, assigning local items should not be given absolute precedence. It is simply false that assigning local items "is obviously the least costly" as the comment says. (That we hard code the cost to 0 for local items is also an arbitrary restriction in Koha, there is no technical reason as to why we shouldn't allow the libraries to set a cost for allocating local items.) I am currently working on a solution based on the Hungarian Algorithm. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 75