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

[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 42889] New: Trigger SQL autocomplete by pressing TAB
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '26

29 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42889 Bug ID: 42889 Summary: Trigger SQL autocomplete by pressing TAB Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Target Milestone: --- SQL Autocompletion is great but it can sometimes be annoying, especially when copying and pasting code. It triggers when you press Enter, which can sometimes be a problem. If it were triggered by pressing the TAB key, that would make its behavior more predictable. What do you think of that idea? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 42935] New: Koha::Item->_status croaks when an item references a non-existent item type
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '26

29 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42935 Bug ID: 42935 Summary: Koha::Item->_status croaks when an item references a non-existent item type Initiative type: --- Sponsorship --- status: 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: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Koha::Item->_status calls $self->item_type->notforloan. item_type resolves via Koha::ItemTypes->find( $self->effective_itemtype ), which returns undef when the item's effective item type is set to a value that has no matching row in the itemtypes table. _status then croaks with: Can't call method "notforloan" on an undefined value at Koha/Item.pm This is the non-NULL-but-invalid case (an orphaned itype value, not an empty one). Impact: a 500 on GET /api/v1/biblios/{biblio_id}/items (the _status embed), so the catalogue detail items table fails to load for the whole record if any one of its items references a non-existent item type. The state is not reachable through normal editing; it arises out of band, e.g. deleting an item type still referenced by items, or an SQL import/migration - which Koha already flags as a data inconsistency (Koha::Database::DataInconsistency::invalid_item_type). To reproduce (item-level itypes): 1. UPDATE items SET itype = 'NOPE' WHERE itemnumber = <X>; ('NOPE' being any value absent from the itemtypes table) 2. Open that record's detail page in the staff interface. => the items table fails to load; the plack log shows the croak above. Expected: the item row loads; a non-existent item type must not be treated as a croak (and should not count as not-for-loan). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 42934] New: Koha::Item->home_library/holding_library croak when an item's branch is NULL
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '26

29 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42934 Bug ID: 42934 Summary: Koha::Item->home_library/holding_library croak when an item's branch is NULL Initiative type: --- Sponsorship --- status: 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: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- items.homebranch and items.holdingbranch are nullable. When either is NULL, Koha::Item->home_library / ->holding_library croak with: DBIC result _type isn't of the _type Branch Impact: a 500 on GET /api/v1/biblios/{biblio_id}/items, so the catalogue detail items table fails to load for the whole record if any one of its items has a NULL home or holding branch. The NULL state is not reachable through normal item creation/editing (those always set the columns), only via out-of-band data such as an SQL import or migration, which Koha already flags as a data inconsistency (Koha::Database::DataInconsistency::invalid_item_library). To reproduce: 1. UPDATE items SET holdingbranch = NULL WHERE itemnumber = <X>; 2. Open that record's detail page in the staff interface. => the holdings table fails to load; the plack log shows the croak above. Expected: the item row loads, with an empty home/holding library. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[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 5789] Fines don't work when items have null homebranch
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '26

29 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5789 Jonathan Druart <jonathan.druart(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |RESOLVED Resolution|--- |WONTFIX --- Comment #19 from Jonathan Druart <jonathan.druart(a)gmail.com> --- Marking invalid. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[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 42869] New: Add REST API coding guideline for async job endpoints (202 Accepted)
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '26

29 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42869 Bug ID: 42869 Summary: Add REST API coding guideline for async job endpoints (202 Accepted) Initiative type: --- Sponsorship --- status: 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Target Milestone: --- Koha currently has several REST API endpoints that enqueue background jobs and return a job_id. These endpoints incorrectly use HTTP 201 Created, which implies a resource was durably created and is immediately addressable. Per HTTP semantics, endpoints that accept a request for asynchronous processing should return 202 Accepted with a Location header pointing to the job tracking endpoint (/api/v1/jobs/{job_id}). Affected endpoints: - POST /api/v1/erm/eholdings/local/titles/import_from_list (returns 201) - POST /api/v1/erm/eholdings/local/titles/import_from_kbart_file (returns 201) - POST /api/v1/cover_images/batch (fixed in bug 42404) This bug tracks: 1. Adding REST3.2.1.2 to the coding guidelines wiki 2. Updating existing endpoints to comply See also: Bug 42404 Wiki page: https://wiki.koha-community.org/wiki/Coding_Guidelines_-_API#REST3.4.1_POST -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[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