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

[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 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 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

[Bug 37446] New: Home/holding library facets missing user friendly label
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37446 Bug ID: 37446 Summary: Home/holding library facets missing user friendly label Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org After upgrading to 24.05, the default Elasticsearch-Koha installation has facets for "Holding libraries" and "homelibrary" (see screenshot). Bug 35138 introduced a search_field atomicupdate that changed holdingbranch and homebranch labels based on DisplayLibraryFacets system preference the following way: "holdinglibrary" => "Holding libraries" "homelibrary" => "Home libraries" If DisplayLibraryFacets was set to "both", both labels would be updated. If not, only one of them is changed. DisplayLibraryFacets defaults to "holding" meaning a default Koha setup would only update "Holding libraries" and leave "homelibrary" as it is. https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=165813&action=d… This creates an unfriendly facet label "homelibrary". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 27063] New: Allow changing which record an order is linked to
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27063 Bug ID: 27063 Summary: Allow changing which record an order is linked to Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org At the moment if the basket is still open you can update the bbliographic details of an order or overwrite the existing record via Z39.50, but if you notice that you have used the wrong record, there is no way to fix this. It would be great if it was possible to change the record an order is linked to while the basket is still open. This should explicitly allow to use a record that is already in the catalog. -- There is also a use case here for libraries using standing orders for tracking electronic resources such as series. They usually place the order on the series record. When the volumes arrive they'd like to change it so the acq information is tied to the volume. But without using items (which is not the case here for electronic resources), this is not possible. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 39

[Bug 37109] New: Don't provide old claims fields when duplicating acquisitions orders
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37109 Bug ID: 37109 Summary: Don't provide old claims fields when duplicating acquisitions orders Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org The following fields that used to be in the aqorders table for claims are still initialised when duplicating orders. They aren't stored anywhere so don't cause a problem, but they don't need to be set at all. * claims_count (dropped in Bug 24161) * claimed_date (dropped in Bug 24161) * placed_on (no evidence of this field existing in aqorders) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 32722] New: Mandatory subfields from Unimarc framework shouldn't block the creation of a bib record when field itself is optional.
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32722 Bug ID: 32722 Summary: Mandatory subfields from Unimarc framework shouldn't block the creation of a bib record when field itself is optional. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibault.keromnes(a)univ-paris8.fr QA Contact: testopia(a)bugs.koha-community.org Created attachment 145658 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=145658&action=e… List of mandatory subfields BZ30733 added many mandatory subfields in UNIMARC default framework, following the IFLA manual updates. Thing is, most of those mandatory subfields are within an optional field, so they're supposed to be mandatory only if the field is used. Yet Koha blocks the record's creation with ~60 mandatory subfields. Most practical solution would probably be to remove the mandatory flag to said subfields (the list is attached to the bug). Exception are 100$a and 200$a (the fields being mandatory too it makes sense) Also have a doubt concerning 099$t and 942$c, that are not actually Unimarc, but Koha specifics, storing biblioitems.itemtype. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 65

[Bug 36662] New: ILL - t/db_dependent/Illrequest should not exist
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36662 Bug ID: 36662 Summary: ILL - t/db_dependent/Illrequest should not exist 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: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 35581 Following up restructuring of ILL classes from bug 35581, the t/db_dependent/Illrequest directory should be deleted and its content moved into t/db_dependent/ILL/Workflow and/or t/db_dependent/ILL/Request Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35581 [Bug 35581] ILL Koha classes are not consistent -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18