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

[Bug 27507] New: Search host record using control number identifier / organization code
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27507 Bug ID: 27507 Summary: Search host record using control number identifier / organization code Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 11175 In /cgi-bin/koha/catalogue/detail.pl currently if you are viewing a record with 773w field the page shows "In: XXXX" with a search link to the host record. Currently when the 773w field format is in the LOC format of (OrgCode)ControlNumber we only search using the ControlNumber part. When importing records to Koha from different databases it is necessary to search also using the organization's code that is in the parentheses – otherwise we get in the results also unrelated records from other organizations. We need the 003 / Control-number-identifier search addition from bug 11175 to implement this. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11175 [Bug 11175] Show the parent record's component parts in the detailed views -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 34

[Bug 21820] New: Zebraqueue should not be added to
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21820 Bug ID: 21820 Summary: Zebraqueue should not be added to Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com In bug 20244 we identified that the zebraqueue is still being appended to when the searchengine preference is set to ElasticSearch.. unfortunately zebra may still be in use in parallel to Elastic to provide a public SRU/z3950 gateway.. as such we can't bind on just the syspref to know whether we should stop adding to the zebraqueue or not. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 53

[Bug 41268] New: Circulation rules script has many conditionals
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41268 Bug ID: 41268 Summary: Circulation rules script has many conditionals 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Focusing on delete-branch-item-rule operation we have four code paths: 1 - if the branch is '*' and itemtype is '*' 2 - if branch is '*' and itemtype is specific 3 - If branch is specific and itemtype is '*' 4 - if branch is specific and itemtype is specified The only difference in these being that we pass 'undef' instead of '*' when star is set. I don't undertstand why we can't set a variable to 'undef' if necessary? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 38436] New: Unable to hide a column in the holdings table in the staff interface
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38436 Bug ID: 38436 Summary: Unable to hide a column in the holdings table in the staff interface Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Staff interface 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 In the holdings table in the staff interface, if a column has a value, it is show regardless of the table settings. I think this is a regression from previous behaviour. I tested it on 23.05 and 24.05 and the table settings are taken into account and hide the undesired column. A use case example is for single-library system who want to simplify/shorten the holdings table, they might choose to hide the holding library column as it's always going to be the same as the home library. Having those two columns only doubles the information uselessly for them. To recreate : 1. View a record in the staff interface 2. In another tab, go to Administration > Table settings > Catalog > holdings_table and check 'is hidden by default' for holdings_holdingbranch 3. Go back to the tab with the record and refresh the page --> The 'Current library' column is still there -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 136

[Bug 33462] New: Force password change for new patrons
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33462 Bug ID: 33462 Summary: Force password change for new patrons Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Patrons that register via OPAC create whatever password they want. But when staff create a patron account, patrons are given a password. It would be preferred if patrons were forced to change their password after first logging in when a staff member creates the account. Unfortunately, the password expiration field is not available when creating the account. It is only editable after. It would be ideal if the password field were shown, even when adding a new patron, and the patron category setup page had an option next to expiration settings to force patron to change password at login when entered by staff. Then, when a staff member is adding the new patron, the date could be defaulted to today. The OPAC self registration would not need to do this. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 121

[Bug 37893] New: Migrate some SIP configuration into the staff client
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Bug ID: 37893 Summary: Migrate some SIP configuration into the staff client 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 The 'accounts' and 'institutions' sections of the SIP Server configuration should be able to be moved into the Koha Staff Client.. this would help librarians understand what settings are in place and allow them to make small changes to those configurations as required. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 141

[Bug 38259] New: Adjust DT's lengthMenu option
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38259 Bug ID: 38259 Summary: Adjust DT's lengthMenu option 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 Depends on: 36640 https://datatables.net/reference/option/lengthMenu https://cdn.datatables.net/2.0.0/ """ lengthMenu now easier to use, being an array of values, which can either be integers or a label / value object. The old 2D array form is still supported via the legacy integration. """ """ Legacy DataTables 1.x used a 2D array rather than objects to support languages. The first inner array is the page length values and the second inner array is the displayed options. This is still supported in DataTables 2, although now deprecated. """ Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36640 [Bug 36640] Upgrade DataTables from 1.13.6 to 2.x -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 34551] New: Don't allow Z39.50 import if MARC can't be converted to MARCXML
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34551 Bug ID: 34551 Summary: Don't allow Z39.50 import if MARC can't be converted to MARCXML Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl As I note on bug 34014 and bug 34549, if you've got the wrong encoding on your Z39.50 server, you can wind up importing MARC data that contains invalid data (like control characters). During copy cataloguing, there should be a warning that there's a problem with the data (possibly because of Z39.50 server config). That way we have librarians raising the flag that there's a problem before the data is in Koha rather than us doing cleanup after it's been imported. (Of course, bulk loaded MARC will still be a problem, but baby steps...) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 41162] New: Warn that printing large barcode ranges can lead to running out of memory
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41162 Bug ID: 41162 Summary: Warn that printing large barcode ranges can lead to running out of memory Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: philip.orr(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org If you are using the barcode range option in the label creator, if your barcode range is too large, your Koha server may run out of memory before the process finishes. This causes out of memory errors. This could happen if a library had e.g. "100101223" as their last used barcode and they wanted to print the next 50 barcodes and they make a mistake while entering the "To:" field in the barcode range creator. From: 100101224 To: 1000101274 You could very easily accidentally cause the label-create.pl process to create insane amounts of barcodes. In this case 900 million barcodes would be created, if my math is right. :) The memory usage will slowly increase as barcodes are created and "eventually" there will be no more memory left, causing OOM killer to strike. We should at least warn in the barcode range creation tool that such problems can happen if you aren't careful while entering values. I don't know if there's a good way to stop users from entering too large ranges, maybe there is a valid use case for a large barcode range if you have enough memory. To reproduce (assuming you are on ktd): 1. Check your current memory usage, e.g. with "ps aux --sort -rss" (or "free -h" to see how much memory is still free) 2. Make sure you know how to kill a process in Debian, e.g. "killall -9 /kohadevbox/koha/labels/label-create-pdf.pl" - you will need it soon.. 3. Go to Cataloging -> Label Creator -> Print barcode range 4. Enter in a number in "From:" and a crazy high number in "To:"; see above for an example 5. Print range -> Export (doesn't matter which templates etc.) -> Click on "Download as PDF" 5. Check your memory usage again, it should start spiking over the next minutes. The guilty process should be /kohadevbox/koha/labels/label-create-pdf.pl (assuming you are on ktd). 6. Either kill the process or you will run out of memory -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 35066] New: In the Holds Queue, add ability to decline to fill a hold and automatically push to the next branch
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35066 Bug ID: 35066 Summary: In the Holds Queue, add ability to decline to fill a hold and automatically push to the next branch Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: catrina(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com For libraries using the holds queue, they should have the ability to deny filling the hold so it would push the item onto the next branch's holds queue without having to wait for the cron to run. Right now, the only way to move an item off a library's queue is to mark it as missing/lost or damaged. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17