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

[Bug 40508] New: Set maxlength in marc21_framework_DEFAULT.yml
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '26

22 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40508 Bug ID: 40508 Summary: Set maxlength in marc21_framework_DEFAULT.yml Change sponsored?: --- 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 By explicitly setting maxlength in marc21_framework_DEFAULT.yml, we can change the default maxlength for fields in the default framework (and to a degree the ACQ framework). See Bug 40471 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 40471] New: Long barcodes in "Add item" throw 500 error
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '26

22 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40471 Bug ID: 40471 Summary: Long barcodes in "Add item" throw 500 error Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging 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 If you try to enter a very long barcode for an item in the "Add item" screen, you'll get a 500 error and the following in the logs: [WARN] DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Data too long for column 'barcode' at row 1 at /kohadevbox/koha/Koha/Object.pm line 174 It should be trivial for us to add length limit checks in the HTML and the Perl. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 30328] New: Add ability to generate barcode with branch specific prefix
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '26

22 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30328 Bug ID: 30328 Summary: Add ability to generate barcode with branch specific prefix 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: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl We should add more flexibility to generating barcodes by letting libraries define branch specific prefix for their barcodes. For this we need to add new barcode option to syspref "autobarcode" and new systempreference where prefixes are set. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 48

[Bug 40997] New: Javascript error prevents saving when an instance of an 'important field is deleted
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '26

22 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40997 Bug ID: 40997 Summary: Javascript error prevents saving when an instance of an 'important field is deleted Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When a record has multiple instances of a field marked as 'important' and a cataloger removes one or more of the instances, and one is left in place, saving the record fails with: Uncaught TypeError: can't access property "getElementsByTagName", elem is null AreFieldsNotOk http://localhost:8081/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&… Check http://localhost:8081/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&… onOption http://localhost:8081/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&… <anonymous> http://localhost:8081/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&… jQuery 2 To recreate: 1 - In Admin - MARC bibliographic frameworks edit the default framewwork and edit 650 tag and mark it as important 2 - Go to cataloging -> new from z39.50 3 - Find a record with mulltiple 650 fields 4 - Delete one of the fields 5 - Attempt to save the record - nothing happens 6 - Check the console log in the browser, see the error noted above -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 42034] New: Add diff support to system preference action logs
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '26

21 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42034 Bug ID: 42034 Summary: Add diff support to system preference action logs Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Blocks: 37940 The action logging in Koha/Config/SysPref.pm does not pass the $original parameter to logaction(), so no structured diff is generated in the action_logs.diff column. Affected calls in Koha/Config/SysPref.pm: - SYSTEMPREFERENCE/MODIFY or ADD (~line 47): C4::Log::logaction( 'SYSTEMPREFERENCE', $action, undef, $self->variable . ' | ' . $self->value ); (concatenates variable name and new value into a string; no before state) - SYSTEMPREFERENCE/DELETE (~line 63): C4::Log::logaction( 'SYSTEMPREFERENCE', 'DELETE', undef, " $variable | $value" ); System preference changes are important for configuration audit trails. This bug covers updating store() in Koha::Config::SysPref to capture the pre-change value and pass it as $original, and to pass a structured hashref (e.g. { variable => ..., value => ... }) as $infos so the diff mechanism can produce a clear before/after comparison. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37940 [Bug 37940] [OMNIBUS] All modification logged via action logs should include original to create JSON diff -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 42054] New: Group holds and real time holds queue: multiple titles show at once
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '26

21 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42054 Bug ID: 42054 Summary: Group holds and real time holds queue: multiple titles show at once Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com If multiple items that could satisfy a group hold are available (and all else being equal with transport costs and hold queue priority), all of them show on the holds queue at the same time for libraries using the real-time holds queue. This includes showing on multiple libraries' queues at once if items are available at different holding libraries. This is likely to cause significant frustration with libraries if multiple items are pulled, but then all except one have to be reshelved after the first one triggers to fill the hold. To replicate: -Make sure the library is using the real-time holds queue. -Identify multiple titles that have an available item and no other holds. Items may be at the same location or at multiple branches. -Place a group hold on those titles for a patron. -Note that the holds queue (or queues, if one title is at another branch) lists all of the available titles. Each title is only listed once - so, if Bib A has copies available at Main and North, the title will only show on one library's queue. But if items from Bibs A, B, and C are all available, all of them will show on the holds queue(s). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 16544] New: Changes to circ rules should be logged.
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '26

21 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16544 Bug ID: 16544 Summary: Changes to circ rules should be logged. 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: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com At present, changes to circulation rules are not logged. This means that there is no way to determine what circulation rules were in effect at a given time, which makes historical trouble-shooting impossible. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 33

[Bug 39233] New: Non-patron guarantor info not dropped when patron category is updated
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '26

21 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39233 Bug ID: 39233 Summary: Non-patron guarantor info not dropped when patron category is updated Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When child patrons category is updated via update_patrons_category.pl patrons relationship with their guarantor is dropped from borrower_relationships table. But non-patron guarantees info is still kept in borrowers table. To reproduce: 1. Find child patron with non-patron guarantor or create one. 2. Update patrons age so that their category is updated when you run following: perl misc/cronjobs/update_patrons_category.pl --confirm --too_old --from K --to PT 3. Check patrons info from borrowers table. => Note that values in contactname, contactfirstname and relationship columns were not dropped. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 41698] New: Add maintenance script to revert found holds for items currently checked out
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '26

21 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41698 Bug ID: 41698 Summary: Add maintenance script to revert found holds for items currently checked out Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz For reasons unknown, it is possible to get into a situation where an item is both checked out to one patron and associated with a found hold for another patron. We should add a script to Koha to fix items in this situation by reverting the found holds. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 41844] New: Save button does not work in cataloging when the first important repeatable field is deleted
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '26

21 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41844 Bug ID: 41844 Summary: Save button does not work in cataloging when the first important repeatable field is deleted Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When a MARC subfield is marked as Important and Repeatable in the bibliographic framework, it becomes impossible to delete the first occurrence of that field in the cataloging editor. If the first occurrence is deleted, the Save button does not work and the record cannot be saved. To test: 1- Go to Administration -> MARC bibliographic framework and click View default framework 2- Search for tag 653 and click Edit subfields 3- Click on subfield $a 4- Select Important, Repeatable, In 'Managed in' select tab 6 and in 'Visibility' select: OPAC, Staff interface and Editor 5- Save the framework 6- Find or create a record using the default framework. 7- Add a value in 653$a, clone the field and add a value in the second occurrence then save the record. 8- Edit the record again 9- Delete the first 653 field. 10- Click Save ---> It's impossible to save the record -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6