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

[Bug 41129] New: Migrate place_booking.js to a Vue island.
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41129 Bug ID: 41129 Summary: Migrate place_booking.js to a Vue island. Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Since the bookings functionality requires a significant amount of reactivity due to many interdependent inputs to achieve a good UX, this bug is intended to deprecate place_booking.js in favor of a Vue island that makes this much easier. The goal here is to have a Vue based component that is used for the Staff Interface as well as the OPAC to avoid duplication and diverging implementations and also makes it easier to keep track of problems that then don't need to be fixed in two places. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 302

[Bug 38948] New: Modal error on some pages: Can't access property "backdrop"
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38948 Bug ID: 38948 Summary: Modal error on some pages: Can't access property "backdrop" Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 35402 I know I've seen this in more than one place, but I've just confirmed that it appears in the console on the item add/edit page: Uncaught TypeError: can't access property "backdrop", this._config is undefined _initializeBackDrop http://127.0.0.1:8081/intranet-tmpl/lib/bootstrap/bootstrap.bundle.min_24.1… On http://127.0.0.1:8081/intranet-tmpl/lib/bootstrap/bootstrap.bundle.min_24.1… <anonymous> http://127.0.0.1:8081/intranet-tmpl/prog/js/cookieconsent_24.1200003.js:20 <anonymous> http://127.0.0.1:8081/intranet-tmpl/prog/js/cookieconsent_24.1200003.js:197 bootstrap.bundle.min_24.1200003.js:6:52582 I think it's new since the Bootstrap 5 upgrade. Some web searches turn up information like "The problem is that the Modal has not been loaded into the DOM at this stage and therefore is undefined when the getElementById action is performed. The solution was to wait until the DOM is loaded." This would make sense considering the add/edit item page is one of those pages where the JS is loaded at the top of the page rather than the bottom. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35402 [Bug 35402] Update the OPAC and staff interface to Bootstrap 5 -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 35837] New: It would be useful to understand what plugins are being used in the wild.
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35837 Bug ID: 35837 Summary: It would be useful to understand what plugins are being used in the wild. 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org HEA hasn't seen much love of late.. it would be great to send back statistics on plugins used in an installation. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 41445] New: Wrong info about holds selection after hold suspending
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41445 Bug ID: 41445 Summary: Wrong info about holds selection after hold suspending Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: roman.dolny(a)jezuici.pl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com After suspending a hold at patron's holds tab, incorrect information about holds selection is displayed. To reproduce: 1. Have unsuspended hold(s). 2. Go to patron's account, "Details" or "Check out", and "Holds" tab. 3. Click "Suspend" button in "Suspend?" column and confirm modal. 4. Notice: 4.1 checked header checkbox (first column) - not correct, checkbox(es) below are not checked 4.2 number of holds selected in line below the holds table - not correct, checkbox(es) above are not checked, buttons "Cancel selected" and "Suspend selected" are active -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 70

[Bug 30557] New: Add ability to create Item lists
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30557 Bug ID: 30557 Summary: Add ability to create Item lists Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: estherm(a)sodaspringsid.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl This is relevant for multi-branch installations. Lists currently appear to be primarily bibliographic lists. This creates a problem when sorting lists by call number. In this scenario there may be multiple items from different libraries using different call number schema attached to a single bibliographic record. The list cannot be sorted accurately by call number. It would be helpful if there was an option for an item based list. In this scenario items are added to a list for a specific branch. The call number sort will then sort correctly because the call number schema will be consistent for the branch. An item list would display the same information as a bibliographic list with the exception of additional branches which may also have the item. A typical use case would a library creating an item list, sort by call number, and then use that list to go to the shelf to pull the items in order. This is currently not possible in a multi-branch installation without a bit of work. It would require downloading the list and then cleaning up the list to be useful for this kind of work. It may be possible to create a report that will do this, but it would be a nice added functionality in the List tool. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 197

[Bug 40626] New: Edit button in item holdings table on bib details page should offer the same options as on Manage Items
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40626 Bug ID: 40626 Summary: Edit button in item holdings table on bib details page should offer the same options as on Manage Items Change sponsored?: --- 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl On the bib details page (/cgi-bin/koha/catalogue/detail.pl) each item has an Edit button in the holdings table. On the Manage Items page (/cgi-bin/koha/cataloguing/additem.pl) each item gets an Actions button that allows the choice of Edit, Duplicate, Print label, Delete, and OPAC view. If you enable LocalCoverImages, the bib details Edit button gets an added side-option allowing selection of Upload Image with 2 clicks (Edit still only takes 1 click). One cannot add an item-level cover from the manage items page. It would be preferable if these two buttons were identical, with each being the sort of two-part button we see on bib-detail when LocalCoverImages is enabled. The button should select Edit when clicked normally, but also allow a click for additional options Duplicate, Print label, Delete, and OPAC view. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 22994] New: Elasticsearch ability import mappings and facets settings
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22994 Bug ID: 22994 Summary: Elasticsearch ability import mappings and facets settings 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: black23(a)gmail.com Target Milestone: --- -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 33446] New: Revert transit status should have the option to cancel the item transfer as well
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33446 Bug ID: 33446 Summary: Revert transit status should have the option to cancel the item transfer as well Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently, when a hold's transit status is reverted, the item remains in-transit until the transfer is completed by a check-in. This makes sense if the item actually is still in-transit, but there are other situations in which this transit status is incorrect and may not be easy to remove. For example, in our system, we have HoldsAutoFill enabled. Occasionally there are exceptions where we don't want a book to be put in transit for a hold, but instead to remain available at its home branch. If the staff member reverts the transit status on the hold, the item still shows as In Transit. But they can't check in the item to complete the transfer without causing the hold to trap again. In this situation, the book shouldn't be showing as In Transit, but there's no simple way to remove that status. It's several extra steps at best to manually cancel the transfer (and most of our staff don't know how to do this, as manual transfers are not a normal part of our workflow, so many items retain an incorrect "In transit" status indefinitely). When a hold's transit status is reverted by the sending librarian because they're not planning on sending the book for whatever reason, it would be great if they could revert the hold transit status and cancel the item transfer all in one step. This could be something as simple as a checkbox option or a drop-down, so that the user can choose between "Revert transit status" versus "Revert transit status and cancel item transfer". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 36549] New: es_indexer_daemon.pl leaks memory
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36549 Bug ID: 36549 Summary: es_indexer_daemon.pl leaks memory Change sponsored?: --- Product: Koha Version: master 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org background_jobs_worker.pl runs its tasks in child processes which return their memory to the OS when they complete. es_indexer_daemon.pl runs everything in itself which means if it needs to allocate a large amount of memory for an indexing job, it will hold on to that memory allocation for its entire process life. -- I've got an es_indexer_daemon.pl which is using over 1GB of memory. Once it's done with its indexing activity, I'm going to restart it to get it back down to a more reasonable amount of allocated memory. I reckon we should be forking off child processes to do the worker. We don't need many. We just need 1 that is short lived so that it can return the memory back to the OS. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 36165] New: Update "Tools" landing page to be more consistent with 'Cataloging' and 'Circulation' landing pages
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36165 Bug ID: 36165 Summary: Update "Tools" landing page to be more consistent with 'Cataloging' and 'Circulation' landing pages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Blocks: 36164 We should take inspiration from existing landing pages, Cataloging, Circulation, Reports, and Administration all come to mind. It would be great to have all of these manifest in a more consistent form. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36164 [Bug 36164] Bring more consistency to our module landing pages -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 33