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

[Bug 39823] New: Sushi harvest can fail with no report
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39823 Bug ID: 39823 Summary: Sushi harvest can fail with no report Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk A library was having issues with Sushi harvests, the test connection passed, however, the harvest failed with no info. Dumping the response on the command line: '_content' => '{"Code": 2010, "Message": "Requestor is Not Authorized to Access Usage for Institution"}' It seems _sushi_errors doesn't handle the case of a code and message but no severity marker This was Gale Cengage -- You are receiving this mail because: You are watching all bug changes.

1 28

[Bug 40033] New: admin/background_jobs.pl calls GetPlugins incorrectly
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40033 Bug ID: 40033 Summary: admin/background_jobs.pl calls GetPlugins incorrectly Change sponsored?: --- Product: Koha Version: Main 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: tadeusz(a)sosnierz.com QA Contact: testopia(a)bugs.koha-community.org In the aforementioned script, GetPlugins is used as so: ``` my @plugins = Koha::Plugins::GetPlugins( { method => 'background_tasks', } ); my @plugin_job_types; for my $plugin (@plugins) { my $tasks = $plugin->background_tasks; ``` This currently results in a 500 when it tries to call background_tasks on a plugin that doesn't have it. The reason for this is an incorrect method call to GetPlugins – since there is no invocant, the $params get intepreted as $self (with $params ending up undefined), and so the method filtering doesn't work – which is why we end up calling background_tasks on plugins we did not want to. In the rest of Koha it's universally used as `Koha::Plugins->new()->GetPlugins()`, so it makes sense to follow that trend here. At the same time, I wonder if a more strict linting rules (or a safer API) could've prevented it from happening in the first place. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 38892] New: Patron category 'can be a guarantee' means that same category cannot be a guarantor (bis)
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38892 Bug ID: 38892 Summary: Patron category 'can be a guarantee' means that same category cannot be a guarantor (bis) Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com I think this was not completely fixed in bug 37892. When adding a patron, you cannot choose a guarantor with the same category. To recreate: 1, Go to Patrons 2. Click 'New patron' > 'Kid' 3. Fill out surname and cardnumber 4. Under Patron guarantor, click Add guarantor 5. Search for category = Kid and choose one of the patrons 6. Choose the relationship 7. Click 'Save' --> Error A guarantor cannot be a guarantee. This patron is not a guarantor. This error does not make sense. ***Note that it also blocks editing a patron that has the same category as their guarantor when coming from an upgrade!*** I think this a major, if not critical. I get that the example with 'Kid' does not make much sense, but I just wanted to avoid having to go into patron categories to change the 'Patron' category for example to 'can be guarantee' and make the example with two 'Patron' patrons. Not all libraries classify their patrons with kid/adult. It might be resident/non-resident for example, and a resident parent could have a resident guarantee. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 38411] New: When adding multiple items on receive, mandatory fields are not checked
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38411 Bug ID: 38411 Summary: When adding multiple items on receive, mandatory fields are not checked Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: adolfo.rodriguez(a)xercode.es QA Contact: testopia(a)bugs.koha-community.org This was fixed Bug #34109 for the case where only one item is added (function addItem) When adding multiple items, the function addMulti is used and it doesn't check mandatory fields. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 39044] New: Fund dropdown not populated for order search on acqui-home
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39044 Bug ID: 39044 Summary: Fund dropdown not populated for order search on acqui-home Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The new order search form on acqui-home doesn't get the budgets passed in so has a dropdown that cannot be used To recreate: 1 - Go to Acqusitions 2 - See the dropdown "Fund: All funds" in the order search section 3 - Click it 4 - Feel disappointed -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 39268] New: Tab Switching Issue: 'My Lists' and 'Public Lists' Sticky, Displaying Incorrect Lists Until Page Refresh
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39268 Bug ID: 39268 Summary: Tab Switching Issue: 'My Lists' and 'Public Lists' Sticky, Displaying Incorrect Lists Until Page Refresh Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl There is an issue with the "Your Lists" and "Public Lists" tabs where the list content doesn't update correctly when switching between them. Initially, the lists display correctly. However, when a user clicks between the tabs (e.g., from 'Public Lists' to 'Private Lists' or vice versa), the list content remains stuck on the first tab's content. For instance, if a user starts on the 'Private Lists' tab and switches to the 'Public Lists' tab, the lists from 'Private Lists' continue to display even though the 'Public Lists' tab is selected. Similarly, if a user switches from 'Public Lists' to 'Private Lists', the 'Public Lists' remain visible. This issue persists until the page is refreshed, at which point the lists reset, but the same behavior occurs again upon switching tabs. This causes confusion, especially for staff who need to view both private and public lists and expect the tab content to reflect the selected tab. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 39183] New: If using automatic return claim resolution on checkout, each checkout will overwrite the previous resolution (again)
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39183 Bug ID: 39183 Summary: If using automatic return claim resolution on checkout, each checkout will overwrite the previous resolution (again) Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: emily.lamancusa(a)montgomerycountymd.gov Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The fix from bug 38246 got deleted when a subsequent bug was rebased. :( Same problem, same fix. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 39244] New: Duplicate and change password buttons missing if no borrowerRelationship defined
by bugzilla-daemon＠bugs.koha-community.org 15 Jan '26

15 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39244 Bug ID: 39244 Summary: Duplicate and change password buttons missing if no borrowerRelationship defined Change sponsored?: --- Product: Koha Version: unspecified 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.m.hall(a)gmail.com If borrowerRelationship is empty the "Duplicate" and "change Password" buttons don't show after the patch from Bug 38429 on both 24.11.x and main -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 21272] New: Marc import should warn about mis-matched branch and item-type fields in 952 during marc import.
by bugzilla-daemon＠bugs.koha-community.org 15 Jan '26

15 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21272 Bug ID: 21272 Summary: Marc import should warn about mis-matched branch and item-type fields in 952 during marc import. Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When importing a record that has homebranch (952$a), holding branch (952$b) or item type (952$y) populated, but not matching values in branches.branchcode or itemtypes.itemtype, koha will indicate that items were not imported (via the count of imported items), but not why. This causes frequent confusion among new users. It would be nice to offer mappings between detected branches / item types and the branches and item types already in the system. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 100

[Bug 37950] New: Clarify that ITEMTYPECAT is OPAC-only in the manual
by bugzilla-daemon＠bugs.koha-community.org 15 Jan '26

15 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37950 Bug ID: 37950 Summary: Clarify that ITEMTYPECAT is OPAC-only in the manual Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)ptfs-europe.com, philip.orr(a)lmscloud.de Unless or until search categories become usable in the staff interface (see bug 32258), the manual should be clarified to specify that this feature applies only to the OPAC. Right now, it's not clear from the manual in Administration > Item types or Administration > Authorized values that this isn't available in the staff interface. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4