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

[Bug 42126] New: t/db_dependent/00-strict.t not testing all perl files
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '26

29 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42126 Bug ID: 42126 Summary: t/db_dependent/00-strict.t not testing all perl files Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org First it lists explicitly the directories to process. Obviously it hasn't been kept up-to-date and some are missing (eg.booking). Also Koha is missing (!). Then we should process the files that are in the git repository, and use Koha::Devel::Files to list them. -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 42112] New: Add option for prompting for renewal, always renewing, or never renewing borrower when changing category
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '26

29 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42112 Bug ID: 42112 Summary: Add option for prompting for renewal, always renewing, or never renewing borrower when changing category Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Bug 32581 - Update dateexpiry on categorycode change introduced extra clicks for libraries that change category codes frequently for administrative reasons. There should be an option to not offer the renewal. Ideally the option could be: Always renew/Ask for Renewal/Never renew I'm not sure if it makes more sense to set as a sys pref or as a "when changing to or away from this category" setting. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 48

[Bug 36254] New: Port default PASSWORD_RESET and STAFF_PASSWORD_RESET notices to Template Toolkit syntax
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '26

29 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36254 Bug ID: 36254 Summary: Port default PASSWORD_RESET and STAFF_PASSWORD_RESET notices to Template Toolkit syntax Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: roadmap_24_05 Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Blocks: 15278 These might require a bit of refactoring. Looking at Recovery.pm, it looks like the subroutine is passing a custom key/value pair for passwordreseturl, so I'm not sure if an equivalent has been added for Template Toolkit syntax yet. Also not sure if there are any security implications to consider? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 [Bug 15278] [Omnibus] Port default slips and notices from bespoke syntax to Template Toolkit -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 31162] New: Add a clear cataloguing module home page
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '26

29 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31162 Bug ID: 31162 Summary: Add a clear cataloguing module home page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client 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 The cataloguing module doesn't really have a 'home page' like circulation does. We have a number of tools under the cataloguing banner, we could have a clear jump-in point on the module home page. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 178

[Bug 42150] New: Allow plugins to register Vue islands via registerIsland()
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '26

29 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42150 Bug ID: 42150 Summary: Allow plugins to register Vue islands via registerIsland() Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: me(a)paulderscheid.xyz QA Contact: testopia(a)bugs.koha-community.org The islands module provides Koha's Vue component architecture but does not expose a public API for external registration. This enhancement enables plugins to contribute Vue islands to the staff interface. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 72

[Bug 42189] New: Allow plugins to inject dashboard widgets via a shared Vue widget registry
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '26

29 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42189 Bug ID: 42189 Summary: Allow plugins to inject dashboard widgets via a shared Vue widget registry Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org Koha's Vue module dashboards (ERM, Preservation, etc.) currently have a hardcoded set of widgets. There is no mechanism for plugins to contribute their own widgets that integrate with the existing dashboard infrastructure (WidgetWrapper, WidgetPicker, drag-and-drop, localStorage persistence). This patch set introduces a widget registry that plugins can extend from their intranet_js() hook, along with the build infrastructure needed to make it work correctly across bundle boundaries. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 104

[Bug 40034] New: CheckReserves dies if itype doesn't exist
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '26

29 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40034 Bug ID: 40034 Summary: CheckReserves dies if itype doesn't exist 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 Filing like this becauseI'm not sure how tackle this. I feel tempted to just propose making item types a real FK. In the meantime, this line explodes if the item type doesn't exist on the DB: ```perl if ($item_type) { return if Koha::ItemTypes->find($item_type)->notforloan; } ``` -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 31314] New: Remove GetItemsInfo from opac-reserve.pl
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '26

29 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31314 Bug ID: 31314 Summary: Remove GetItemsInfo from opac-reserve.pl 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: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 31306 Blocks: 27272 Bug 27272 is going to remove C4::Items::GetItemsInfo in favour of Koha::Items->search_ordered. Here we are going to deal with opac-reserve.pl Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27272 [Bug 27272] Move C4::Items::GetItemsInfo to Koha namespace https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31306 [Bug 31306] Add Koha::Items->search_ordered method -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 36957] New: Item in transfer should start floating in its floating library without user clicking the "Cancel transfer"-button
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '26

29 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36957 Bug ID: 36957 Summary: Item in transfer should start floating in its floating library without user clicking the "Cancel transfer"-button Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: piia.semenoff(a)ouka.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When item is in transfer and it is checked in in a library where it could float, a notification/pop-up about transport will appear on the screen. User must end the transfer by clicking “Cancel transfer”-button. Only then will the item end the transport and start floating in the holding library. Even if the item is in transfer somewhere else (and there are no holds waiting) and it is checked in in a floating library, it should not give the pop-up: “Wrong transfer detected, please return item to…” . Instead it should just start floating without having to click the canceling-button. Koha asks for transfer cancelation even if we have saved in the AutomaticItemReturn-preference “Don’t automatically transfer items to their home library when they are checked in.” -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 39058] New: Top and left menu should have a fixed position
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '26

29 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39058 Bug ID: 39058 Summary: Top and left menu should have a fixed position Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com It would improve Koha usabilty - to always display the top elements (navbar, header_search, maybe sub-header) even if the user scroll down the page - to always display the left menu, and to make it collapsible if the user choose to -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21