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

[Bug 26197] New: Using Rancor while cataloging doesn't appear to check for existing records
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26197 Bug ID: 26197 Summary: Using Rancor while cataloging doesn't appear to check for existing records Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Upon testing this, while cataloging a new record using the basic editor Koha will find a duplicate record existing in Koha but didn't find the same duplicate using the Advanced Editor. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 43733] New: Option to hide the cataloging search
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43733 Bug ID: 43733 Summary: Option to hide the cataloging search Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- Searching the reservoir is unnecessary for a number of libraries and hinders the use of Koha. Koha's general search bar should be configurable (perhaps via a system preference?) to hide the "cataloging" search that queries the reservoir. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 37557] New: Hiding whole fields in MARC bibliographic frameworks
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37557 Bug ID: 37557 Summary: Hiding whole fields in MARC bibliographic frameworks Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: bibliotheca(a)klastervyssibrod.cz QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl I based a new MARC bibliographic framework on the default one and don´t need most of the fields there, but do not want to delete them, because it´s possible that I´ll want to use them in the future, so I would rather just hide them. But unluckily it´s only possible to hide the subfields one by one and the whole field disappears only after I hid all of the corresponding subfields - which takes very much time to do and is pretty tedious. So what I suggest is to make it possible to hide whole fields in a MARC bibliographic framework with one click (or even to be able to select more of them at once and then hide them all) without having to hide all the subfields one by one first. (By hiding I mean to uncheck all the visibility options by a subfield, or to check the "Flagged" option there.) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 43190] New: Staff with only fast_cataloging permission no longer directed to 'Add item' screen when creating a Fast Add record from checkout
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43190 Bug ID: 43190 Summary: Staff with only fast_cataloging permission no longer directed to 'Add item' screen when creating a Fast Add record from checkout Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Keywords: regression Severity: normal Priority: P5 - low Component: Cataloging 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 Target Milestone: --- In 26.05, a staff member who only has the Fast cataloging (fast_cataloging) permission under the Edit catalog (Modify bibliographic/holdings data) (editcatalogue) umbrella is no longer directed to the Add item screen after creating a Fast Add bib from the checkout screen. To recreate: -Find/create a staff member with full circulation permissions, and only fast_cataloging from the editcatalogue group. -As that staff member, try to check out a nonsense barcode to a patron. -Click the '+Add record using fast catalog' button. -Add bib information, then save the record. -Note that you're returned to the bib detail screen for the bib you just created instead of the 'Add item' screen. From here, the staff member can only add an item by clicking Edit > Manage items. On that screen, the barcode they originally entered isn't pre-populated, and they aren't returned to the checkout screen once the item is added. Staff with the top-level editcatalogue permissions don't appear to have a change in behavior from 25.11: from using '+Add record using fast catalog' at checkout, they can create a fast add bib and then are directed to the 'Add item' screen with the barcode pre-populated. Once they save the item, they're returned to the checkout screen, and the item checks out automatically. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 43598] New: Catalog search disappears from main search bar after bib deletion
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43598 Bug ID: 43598 Summary: Catalog search disappears from main search bar after bib deletion Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- When we delete a bib record, we are taken to the advanced search page, but the main search bar no longer has a catalog search. I know the search is below in the page, but this is inconsistent with other workflows. When you are doing your searches primarily on the main search bar and then delete a record, you have to mentally pay attention to the fact that the search bar no longer searches the catalog after that action. We should keep the catalog search function on the header search bar, even in the advanced search page. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 43477] New: When editing an item search bar should display search catalog instead of cataloging search
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43477 Bug ID: 43477 Summary: When editing an item search bar should display search catalog instead of cataloging search Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- When editing or creating an item search bar currently display "cataloging search" (search in the catalog and the reservoir) I think it is not what most librarians expect. It would be better to display "search catalog" instead. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 43819] New: Provider login icon at Log in to your account
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43819 Bug ID: 43819 Summary: Provider login icon at Log in to your account Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: mhby87(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Created attachment 208050 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=208050&action=e… Big icon -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 41963] New: OPAC list view toolbar and action buttons consume most of the screen on mobile
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41963 Bug ID: 41963 Summary: OPAC list view toolbar and action buttons consume most of the screen on mobile Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl On mobile devices, the OPAC virtual shelves/lists view (opac-shelves.pl) has two problems that make it hard to use: 1. The list actions toolbar (New list, Download, Send, Print, Edit, Delete, Share, Sort) and the selections toolbar (Select all, Clear all, Place hold, Remove) are always fully expanded and sticky, consuming 7+ rows of buttons before any list content is visible. There is no way I found to collapse or dismiss them. 2. The per-item action buttons (Place hold, Save to another list, Remove from list, Add to cart) render as full-width block elements with 120% font size, taking more vertical space than the bibliographic information itself. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 14962] Temp Shelving Location / On Display Module
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14962 Lisette Scheer <lisette(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #518 from Lisette Scheer <lisette(a)bywatersolutions.com> --- Thanks Jake! Tooltip for display location has Display capitalized, but it's not capitalized in other tooltips and I would expect it to be lowercase here. Check in behavior should use the American spelling instead of behaviour. The popup when dates are empty is kind of weird, espeically if there's more than one. Could we instead handle it like when a field isn't filled on a patron screen? It jumps to the first required field and highlights it. I believe the display should be able to have blank end date for perpetual displays such as new books. The date isn't auto-calculated at step 5.1.3 if the date is left empty when adding an item at display creation. It's also just making date to remove today if adding from within the display with no date to remove, even if the duration is 30, and looks required but doesn't force you to fill it. Button on detail page doesn't add items but does give a success message. Adding a single item in a display doesn't trim a space at the end. Audit logging, includes UPDATE_ITEM, at least when a superlibrarian adds an item and the diff is blank/just {}. Modify doesn't seem to consistently store the diff. Display details: Name: Summer Reading 2026 Home library: Institut Protestant de Theologie Duration of display: 30 Start of display: 10/16/2026 End of display: 10/17/2026 enabled: check in behavior: do nothing Items: 39999000000252 Date added 10/15/2026 Date to remove 10/15/2026 39999000000238 Date added 10/14/2026 Date to remove: 10/15/2026 Both show as updated on the search results and record in the staff interface and opac, but don't on the OPAC the displays column is empty. On the staff side, the cloumn for displays doesn't show at all. If you change the dates: Start of display: 10/15/2026 End of display: 10/17/2026 39999000000252 Date added 10/12/2026 Date to remove 10/14/2026 39999000000238 Date added 10/16/2026 Date to remove: 10/30/2026 The detail doesn't show the effective branch, but appends the public and non public notes and shows the displays column with a link to the display and shows the display column in the opac as well as the appended public note. When editing a library group, "Is display group" is checked when editing an existing group, even when it does not have it. If you can view from all libraries, you can click the edit and delete buttons but if you try to follow through, it gives either "An error occurred while saving the display" it would be helpful to instead say you don't have permission (or even better, don't show the buttons if they don't have the associated permission for that group. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41598] New: Add information about resetting the superlibrarian password to the manual
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41598 Bug ID: 41598 Summary: Add information about resetting the superlibrarian password to the manual Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)openfifth.co.uk, david(a)davidnind.com, philip.orr(a)lmscloud.de A question that is asked every so often is how to reset the superlibrarian password. We should add information about the misc/devel/create_superlibrarian.pl script to the I think the options would be something like: ./create_superlibrarian.pl --userid <your_username> --password <your_new_password> --branchcode <your_library_code> --categorycode <your_patron_category> As far as I can tell, this isn't covered in the manual. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2