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

[Bug 41561] New: "tab" variable in admin/aqbudgetperiods.pl, tt is not used and should be removed
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41561 Bug ID: 41561 Summary: "tab" variable in admin/aqbudgetperiods.pl,tt is not used and should be removed Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 8117 admin/aqbudgetperiods.pl my $tab = $input->param('tab') ? $input->param('tab') - 1 : 0; This is never used. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8117 [Bug 8117] Divide budget periods into two tabs -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 40777] New: 500 Error: Something went wrong when loading the table Should Exit Cleanly
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40777 Bug ID: 40777 Summary: 500 Error: Something went wrong when loading the table Should Exit Cleanly Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: jyorio(a)equinoxinitiative.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It's possible this is related to/a duplicate of https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40762 but I am not certain. In Koha 24.05 and 24.11, in the staff interface, if a bib with an item without a 952$a and 952$b is imported, when the staff member then goes to the bib record they receive a modal pop-up stating "Something went wrong when loading the table. 500: error". If they click OK on that message, a processing box sits on the screen (you can see the bib loaded behind it) and spins. The console log shows: datatables_24.1107000.js: 408 DataTables warning: table id=holdings_table - Ajax error. For more information about this error, please see https://datatables.net/tn/7 The "processing" box is not modal and it is possible to click on Edit, Manage items, and then edit the problem item to add the missing Home and Current libraries and resolve the cause of the error. This behavior does not occur in 23.11. While, of course, the item needs the Home and Current library, the error alert is a change in expected behavior from staff member perspective. A cleaner exit with a more informative message than a 500 error seems preferable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 69

[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 41292] New: Add "force_password_reset_when_set_by_staff" to column name whitelist
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41292 Bug ID: 41292 Summary: Add "force_password_reset_when_set_by_staff" to column name whitelist Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: george(a)nekls.org QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Bug 37508 added filters to Koha SQL reports and prevents them from using column names containing sensitive information. It also created a whitelist of non-sensitive columns that are accidentally blocked by that same filter. Bug 33462 added categories.force_password_reset_when_set_by_staff as a new column in the database. categories.force_password_reset_when_set_by_staff contains no sensitive data but is still blocked by the filters created in Bug 37508. categories.force_password_reset_when_set_by_staff should be added to the whitelist. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[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 42010] New: Include escaping when using PO numbers in EDI acqusitions
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42010 Bug ID: 42010 Summary: Include escaping when using PO numbers in EDI acqusitions Initiative type: --- Sponsorship Sponsored status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: hdunne-howrie(a)westminster.gov.uk, kyle(a)bywatersolutions.com, testopia(a)bugs.koha-community.org Depends on: 20253 Blocks: 38195 In bug #20253 we added support for using PO numbers as basket names.. we neglected to add escaping to the resulting basketnames that could then be used in corresponding orders. This bug servers to add that escaping as a follow-up to the original enhancement. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20253 [Bug 20253] Optionally use buyer's purchase order number from EDIFACT quote in basket name https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38195 [Bug 38195] EDI/Edifact classes should use Koha::Objects instead of plain DBIC -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 42053] New: Bug 37893 DBUpdate does not always add the new userflags/permissions
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42053 Bug ID: 42053 Summary: Bug 37893 DBUpdate does not always add the new userflags/permissions Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In db_revs/250600035.pl for the SIP2 module there is: unless ( -f $SIPconfigFile && -r $SIPconfigFile ) { say_warning( $out, "Skipping migration. SIP config file not found or unreadable" ); return; } and then later: $dbh->do( q{INSERT IGNORE INTO userflags (bit, flag, flagdesc, defaulton) VALUES (31, 'sip2', 'Manage SIP2 module', 0) } ); So the permissions are only added if there is a SIP config. The permissions should be added no matter what. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 37661] New: Disable/Enable Bookings
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37661 Bug ID: 37661 Summary: Disable/Enable Bookings Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com If libraries are not planning to use the bookings feature, there's no way to hide this option. Even if staff don’t have the manage_bookings permission, they can still set an item as bookable, but the “place booking” button won’t appear for them. It would be nice if the bookings feature could be set to enable/disable via a system preference, similar to EnablePointOfSale, EnableItemGroups, HouseboundModule, ERMModule, ILLModule, and PreservationModule. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 131

[Bug 36540] New: Consider modernising the checkout page to be an Vue page
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36540 Bug ID: 36540 Summary: Consider modernising the checkout page to be an Vue page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface 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 checkouts page is a core function of Koha, The controller has grown very complicated and it can suffer from performance challenges that we keep trying to side step wit preferences work arounds. We should consider working to replace the page with a Vue app and use the modern API's that have been developed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22