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

[Bug 36066] New: REST API: We should not allow deleting open order lines
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36066 Bug ID: 36066 Summary: REST API: We should not allow deleting open order lines Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl CC: tomascohen(a)gmail.com See also bug 10869 and bug 18360. Until now we focused on not deleting order lines in the interface entirely. So it is quite strange that we allow it without any checks on the REST API. In harmony with 18360 we should check if the status is cancelled. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 37

[Bug 36103] New: "Cancel hold" link broken for item level holds
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36103 Bug ID: 36103 Summary: "Cancel hold" link broken for item level holds Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: lasse.pouru(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com 1. Open the "Holds" tab of a record with an item level hold. 2. Select a patron from the patron search. 3. Click on the "Cancel hold" link. (Link appears as it should, e.g. "modrequest.pl?CancelBiblioNumber=58&CancelBorrowerNumber=5&CancelItemnumber=125"). 4. Popup appears. Click "Confirm cancellation". 5. Page loads. Instead of the correct data for the hold to cancel, all of the values in the URL are null, i.e. "request.pl?action=cancel&borrowernumber=undefined&biblionumber=undefined&reserve_id=undefined". The hold is not cancelled. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 36056] New: Clarify subpermissions check behavior in C4::Auth
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36056 Bug ID: 36056 Summary: Clarify subpermissions check behavior in C4::Auth Change sponsored?: --- Product: Koha Version: master 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Looking at C4::Auth::haspermission, it looks like it allows checking: { perm => { subperm_a => 1, subperm_b => 1 } } treating it like subperm_a AND subperm_b. But this use case is not documented. We should add tests and add it to the POD. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 36010] New: Items/AutomaticItemModificationByAge.t is failing randomly
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36010 Bug ID: 36010 Summary: Items/AutomaticItemModificationByAge.t is failing randomly Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 32029 koha_1 | # Failed test 'ToggleNewStatus: conditions on biblio' koha_1 | # at t/db_dependent/Items/AutomaticItemModificationByAge.t line 356. koha_1 | # got: 'agefield_new_value' koha_1 | # expected: 'new_updated_value_biblio' koha_1 | # Looks like you failed 1 test of 20. Koha_Master_My8/1279 First failure from this one that has been pushed recently. I don't recreate locally (even using MySQL8). Maybe something to do with the age comparison if the node is slow? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32029 [Bug 32029] Automatic item modifications by age missing biblio table -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 38035] New: "sound" listed as an available language
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38035 Bug ID: 38035 Summary: "sound" listed as an available language Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: major 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 $ koha-translate --list sound -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 36435] New: Prevent warnings from interrupting koha-run-backups when deleting old backup files
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36435 Bug ID: 36435 Summary: Prevent warnings from interrupting koha-run-backups when deleting old backup files Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Since the changes at Bug 30627, sometimes backup files older than X days don't get deleted as they are meant to. In our case, this happens when: - koha-dump does not return a success status - because `tar -c` throws a warning "tar: var/log/koha/INSTANCENAME/opac-access.log: file changed as we read it" The new dump is created, but the warning is enough to interrupt koha-run-backups before it gets to deleting old backups. This causes excess backups to be stored and fills up the disk. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 45

[Bug 37946] New: Double menu when clicking the caret in Z39.50 search
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37946 Bug ID: 37946 Summary: Double menu when clicking the caret in Z39.50 search Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org When importing a record via Z39.50, you have the possibility of either clicking anywhere to get the Marc/Card/Import menu, or clicking the caret button next the the MARC button. Right now, if you click on the caret, both menus appear. To recreate: 1. Go to Cataloging 2. Click on New from Z39.50/SRU 3. Make a search in the library of congress server for anything (I searched for author: shakespeare) 4. Next to one of the results, click the caret button next to the MARC button --> Two MARC/Card/Import menus appear -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 37947] New: Import from Z39.50 doesn't open the record in editor
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37947 Bug ID: 37947 Summary: Import from Z39.50 doesn't open the record in editor Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Cataloging 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: m.de.rooy(a)rijksmuseum.nl When importing a record from Z39.50, normally choosing "Import" opens the record in the basic editor. However, the record is not opening. To recreate: 1. Go to Cataloging 2. Click on New from Z39.50/SRU 3. Make a search in the library of congress server for anything (I searched for author: shakespeare) 4. Click on one of the results and choose Import --> The basic editor appears, but not the record I tried this in KTD as well as a sandbox with the same result. I tried different records (all from LOC and all with author: shakespeare) but they all do the same thing. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 37542] New: Patron search is incorrectly parsing entries as dates and fetching the wrong patron if dateofbirth in search fields
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37542 Bug ID: 37542 Summary: Patron search is incorrectly parsing entries as dates and fetching the wrong patron if dateofbirth in search fields Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When parsing patron search we try to convert the input into a date for searching against dateofbirth if included in defaultpatronsearchfields This can lead to odd values being converted to incorrect dates. To recreate" 1 - Create a patron with dateofbirth 1994-07-27 2 - Add dateofbirth to DefaultPatronSearchFields 3 - In patron or checkout search, type a cardnumber like '2908800092528' 4 - Note the patron with that birth date is found in autocomplete 5 - Open the browser console (F12) 6 - In the network tab, find the last request (or just remove and add a digit) 7 - Copy the URL from that request and paste into a text editor 8 - Search for 'dateofbirth' 9 - See that the entry has been converted to 1994-07-27 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 37499] New: Remove global variables from addbiblio.pl
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37499 Bug ID: 37499 Summary: Remove global variables from addbiblio.pl Change sponsored?: --- 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: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Depends on: 37429 addbiblio.pl contains a number of global variables. Some if not all of them are state variables that have no business being globals. We should refactor to scope these variables appropriately. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37429 [Bug 37429] Can't edit biblio records anymore (empty form) in 24.05 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4