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

[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

[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 38483] New: C4::Heading::preferred_authorities is not used
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38483 Bug ID: 38483 Summary: C4::Heading::preferred_authorities is not used Change sponsored?: 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: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org C4::Heading::preferred_authorities seems to be not used for ages (maybe never used?) [and the call to _search inside preferred_authorities does not conform to the prototype -- missing $self in the parameter list] -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[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

[Bug 38678] New: GET /deleted/biblios cannot be filtered on `deleted_on`
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38678 Bug ID: 38678 Summary: GET /deleted/biblios cannot be filtered on `deleted_on` Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Because of a wrong mapping, filtering on the `deleted_on` attribute is not possible. To reproduce: 1. Perform this search: GET /api/v1/deleted/biblios { "-and": [ { "me.deleted_on": { ">=": "2024-10-01T08:35:24-05:00" } }, { "me.deleted_on": { "<=": "2024-11-19T08:35:25-07:00" } } ] } => FAIL: You get a 500. The logs say `me.deleted_on` doesn't exist. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29