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

[Bug 37419] New: Deleting the record source deletes the associated biblio_metadata rows.
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37419 Bug ID: 37419 Summary: Deleting the record source deletes the associated biblio_metadata rows. Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: arthur.suzuki(a)biblibre.com, gmcharlt(a)gmail.com, tomascohen(a)gmail.com Depends on: 35919 Blocks: 36372 After applying the Bug 36372, it is possible to manually set record source for a given bibliographic record. At the same time, from /cgi-bin/koha/admin/record_sources it is possible to delete a record source currently being used, without any control. This in turn causes the deletion of all the rows from the biblio_metadata table linked with the record source being deleted, which is fatal. BTW the biblio and biblioitems rows remain in the database. This effect is caused by "CONSTRAINT `record_metadata_fk_2` FOREIGN KEY (`record_source_id`) REFERENCES `record_sources` (`record_source_id`) ON DELETE CASCADE" in biblio_metadata setup. Of course the same effect occurs when deleting the record_sources row by hand, directly in the database. I am not sure if the decision to link biblio_metadata with record_sources with ON DELETE CASCADE is just, even if we controlled the use of the specific record source before deletion (as we do with itemtypes for instance). Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35919 [Bug 35919] Add record sources CRUD https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36372 [Bug 36372] Allow privileged users to set the 'record source' on cataloguing -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 33

[Bug 37868] New: Remove C4::Reserves::ToggleSuspend
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37868 Bug ID: 37868 Summary: Remove C4::Reserves::ToggleSuspend 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 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 30856] New: Remove CanReserveBeCanceledFromOpac
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30856 Bug ID: 30856 Summary: Remove CanReserveBeCanceledFromOpac 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org We already have a method that does the same check, Koha::Hold->is_cancelable_from_opac -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 37480] New: Make C4::Serials::addroutingmember us Koha::Objects
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37480 Bug ID: 37480 Summary: Make C4::Serials::addroutingmember us Koha::Objects 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 37476] New: RANK is a reserved word in MySQL 8.0.2+
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37476 Bug ID: 37476 Summary: RANK is a reserved word in MySQL 8.0.2+ Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org As of MySQL 8.0.2 [1], `rank` is a reserved word and is breaking some code [2]: ``` C4::Serials::addroutingmember(): DBI Exception: DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'rank FROM subscriptionroutinglist WHERE subscriptionid = '59'' at line 1 at t/db_dependent/Serials.t line 227 ``` [1] https://dev.mysql.com/doc/refman/8.0/en/keywords.html [2] https://jenkins.koha-community.org/job/Koha_Main_My8/1322/consoleFull -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 38406] New: Item fields should not be stored on the DB
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38406 Bug ID: 38406 Summary: Item fields should not be stored on the DB 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org After the inclusion of bug 31224, it become clear that Koha is allowing the storage of MARC field 952 in the `biblio_metadatas.metadata` column. I didn't spot it when reviewing bug 29697. To check this, look at Koha::Biblio::Metadata:226~230. In that place, code was added for removing it when retrieving from the DB, so legacy code could be easily ported into using this new code in the Koha::* namespace. Now that we implemented a -somehow- more clear approach, it got highlighted that we should deal with that. In my opinion, we should enforce either rejection, or removal+alert in AddBiblio and ModBiblio instead of the current approach of silently removing them after we allowed to store them. Or maybe we should do both. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 37876] New: Move C4::Serials code to the Koha namespace
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37876 Bug ID: 37876 Summary: Move C4::Serials code to the Koha namespace Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 38424] New: Upgrade redocly/cli to the latest release
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38424 Bug ID: 38424 Summary: Upgrade redocly/cli to the latest release 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org While not critical, our used version is dated and we keep getting warnings about it when `reset_all` is run or at `KTD` startup time. https://github.com/Redocly/redocly-cli/releases -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 37186] New: Cannot delete a rotating collection
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37186 Bug ID: 37186 Summary: Cannot delete a rotating collection Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: cubingguy714(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1. Tools -> Rotating collections 2. Create a rotating collection 3. From rotating collections Action -> Delete 4. Collection is not deleted -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 37253] New: Enhance POST /checkouts endpoint to accept barcode or item_id
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37253 Bug ID: 37253 Summary: Enhance POST /checkouts endpoint to accept barcode or item_id Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: bibliothek(a)th-wildau.de QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com By now a new checkout is built at least by params patron_id and item_id. This makes it a bit difficult if you only have a barcode of the item available, f.e. from RFID middleware applications, as you have to make another API call to retrieve the item_id for a barcode first. I would propose to enhance the POST /checkouts (addCheckout) route to accept either item_id or barcode (external_id in API) as JSON params. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36