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

[Bug 8589] Advanced Search for itemtype and location produces some results that are not useful
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8589 --- Comment #12 from Luis Bataller <luis.bataller(a)xercode.es> --- (In reply to Martin Renvoize (ashimema) from comment #11) > I'm wondering if this is a duplicate of Bug 42835 - ElasticSearch should > have an items index Hi Martin, yes, it's what it does: an items nested index. Thanks for the information; the task wasn't open yet when we started development. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43604] New: commit_file.pl --revert dies: safe_to_delete calls can_edit_items_from on undef
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43604 Bug ID: 43604 Summary: commit_file.pl --revert dies: safe_to_delete calls can_edit_items_from on undef Initiative type: --- Sponsorship --- status: 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- This fixes a regression introduced by bug 33070, where Koha::Item->safe_to_delete assumed C4::Context->userenv->{number} always corresponds to a real Koha::Patron. misc/commit_file.pl sets a dummy CLI userenv with borrowernumber 0: C4::Context->set_userenv( 0, 'batch', 0, 'batch', 'batch', 'batch', 'batch' ); Running --revert on a batch calls C4::ImportBatch::BatchRevertItems, which calls Koha::Item->safe_delete on every item created by the batch. safe_delete calls safe_to_delete, which runs: !Koha::Patrons->find( C4::Context->userenv->{number} )->can_edit_items_from( $self->homebranch ) Since there is no patron with borrowernumber 0, Koha::Patrons->find returns undef, and calling ->can_edit_items_from on undef is a fatal error that aborts the whole script. Other call sites touched by bug 33070 already guard against a missing patron (e.g. Koha::UI::Table::Builder::Items->build_table: nomod => $patron ? !$patron->can_edit_items_from(...) : 0), but Koha::Item->safe_to_delete never got the same guard. Test plan: 1. Stage and commit a batch of records so items get created (e.g. via the Manage staged MARC records tool, or misc/commit_file.pl --batch-number NNN). 2. Run: misc/commit_file.pl --batch-number NNN --revert 3. Without this patch, the script dies with: Can't call method "can_edit_items_from" on an undefined value at Koha/Item.pm line 374. 4. Apply the patch. 5. Run: prove t/db_dependent/Koha/Item.t -- all tests pass, including the new regression test. 6. Repeat step 2 -- the batch reverts successfully. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 33070] New: Get rid of Koha::Patron->can_edit_item and use can_edit_item_from instead
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33070 Bug ID: 33070 Summary: Get rid of Koha::Patron->can_edit_item and use can_edit_item_from instead 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 Bug 20256 introduced a pattern we are trying to avoid for a long time now (old patchset). It should be refactored and cleaned. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 23649] New: Elasticsearch offer an option to weight search results by type
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23649 Bug ID: 23649 Summary: Elasticsearch offer an option to weight search results by type Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com Some libraries would like to be able to prioritize "books" over "large print" , audios, etc in the search results -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 51

[Bug 8589] Advanced Search for itemtype and location produces some results that are not useful
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8589 --- Comment #11 from Martin Renvoize (ashimema) <martin.renvoize(a)openfifth.co.uk> --- I'm wondering if this is a duplicate of Bug 42835 - ElasticSearch should have an items index -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43601] New: Export cataloguing data - add option to exclude item type
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43601 Bug ID: 43601 Summary: Export cataloguing data - add option to exclude item type Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: PC OS: Windows Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: cgresser(a)jesuit.org.uk QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- I don't think it is possible to use the Export data (under Cataloguing) by _excluding_ 1 or more item types. This would be useful, as if exporting in Marc21 - for external MarcEdit work, one cannot easily manipulate that list. Some item types are used for library admin, and should be excluded in the data seen by the external partners. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 42663] New: Koha::Context must be object-oriented designed
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42663 Bug ID: 42663 Summary: Koha::Context must be object-oriented designed Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement 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 Discussion from bug 41892 suggested that the new module Koha::Context should have an Object-oriented interface. -- You are receiving this mail because: You are watching all bug changes.

1 37

[Bug 24288] New: Add wording to authorized value interface to indicate valid code length
by bugzilla-daemon＠bugs.koha-community.org 22 Sep '26

22 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24288 Bug ID: 24288 Summary: Add wording to authorized value interface to indicate valid code length Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Several standard authorized values feed into fields that require a single character code (LOST, NOTFORLOAN, DAMAGED, RESTRICTED, WITHDRAWN). It'd be good to have some wording in the authorized value interface that would indicate this. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 42

[Bug 27512] New: Block creation of invalid authorised values for LOST, NOTFORLOAN, DAMAGED, RESTRICTED, and WITHDRAWN
by bugzilla-daemon＠bugs.koha-community.org 22 Sep '26

22 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27512 Bug ID: 27512 Summary: Block creation of invalid authorised values for LOST, NOTFORLOAN, DAMAGED, RESTRICTED, and WITHDRAWN Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Several authorised value categories have inherent limits on what values can be used. Bug 24288 adds text to the screen to tell you about these limits, but doesn't enforce them. It'd be good to just stop a user from saving a value that won't work. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 40392] New: Staff without create_public_lists can create public list from search results
by bugzilla-daemon＠bugs.koha-community.org 22 Sep '26

22 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40392 Bug ID: 40392 Summary: Staff without create_public_lists can create public list from search results Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In 24.11, staff can create public lists from search results even if they don't have the create_public_lists permission put in place by Bug 13888 - 'Lists' permission should allow/disallow using the lists module in staff. To recreate: -Find or create a staff member with no permissions from the lists group -While logged in as that staff member, perform a catalog search, select the checkboxes on multiple search results, and click the 'Add to list' button -Select the 'New list' option -Note the option to set the new list to public or private - set to 'Public' -Go to Lists, and note that no Public lists tab shows (so you can't see the list you just created) -Next, log in as a staff member with edit_public_list_contents -Go to Lists, and note that the list created by the permission-less staff member shows up in Public lists -Note that the list is also visible in the OPAC -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7