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

[Bug 5920] Remove HTML from downloaded reports in CSV format
by bugzilla-daemon＠bugs.koha-community.org 12 May '26

12 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5920 --- Comment #38 from Mathieu Saby <mathsabypro(a)gmail.com> --- I have opened this bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42331 -- You are receiving this mail because: You are watching all bug changes.

1 0

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

12 May '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 14

[Bug 11340] Make the 'print summary' a custom slip/notice
by bugzilla-daemon＠bugs.koha-community.org 12 May '26

12 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11340 --- Comment #15 from Koha collecto <koha(a)collecto.ca> --- This is still valid et wanted as well with the 25.05 version of Koha. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 11340] Make the 'print summary' a custom slip/notice
by bugzilla-daemon＠bugs.koha-community.org 12 May '26

12 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11340 Koha collecto <koha(a)collecto.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |koha(a)collecto.ca -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 22322] New: Self-checkin module should provide for automatic logins (like self-checkout)
by bugzilla-daemon＠bugs.koha-community.org 12 May '26

12 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22322 Bug ID: 22322 Summary: Self-checkin module should provide for automatic logins (like self-checkout) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: oliver.behnke(a)aei.mpg.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- The self-checkin (SCI) module currently requires to set up a dedicated kiosk terminal for its purpose. The reason being that you can't provide user/password system preferences for an automatic login, like you can for the self-checkout (SCO) counterpart. Our use case is the following: we are already using the SCO module with automatic login of the dedicated SCO patron, and our actual patrons identify themselves via their cardnumber. While they can obviously check in their books via the SCO module, we'd like to streamline the process such that they don't have to login with their cardnumber in order to simply return a book. The SCI module would be ideal for this but, effectively, it can't be used on the same terminal as switching between the modules currently requires a manual login of the dedicated SCI patron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 58

[Bug 34478] Full CSRF protection
by bugzilla-daemon＠bugs.koha-community.org 12 May '26

12 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34478 Jonathan Druart <jonathan.druart(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42535 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42535 [Bug 42535] Remove useless "news_delete" javascript in staff interface -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9083] Remove <<items.content>> form list of placeholders for CHECKIN/CHECKOUT notices
by bugzilla-daemon＠bugs.koha-community.org 12 May '26

12 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9083 Jonathan Druart <jonathan.druart(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=42560 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 42527] New: Impossible to log into OPAC after error when OpacPublic disabled
by bugzilla-daemon＠bugs.koha-community.org 12 May '26

12 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42527 Bug ID: 42527 Summary: Impossible to log into OPAC after error when OpacPublic disabled Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org There's a couple problems here. First: If you disable OpacPublic and go to http://localhost:8080/cgi-bin/koha/bad It generates a form action of "/cgi-bin/kohaerrors/404.pl" because Koha/AuthUtils.pm's get_script_name isn't returning the script name correctly for middleware handled errors. Second: C4/Auth.pm's checkauth probably should allow "errorpage.tt" as part of "@allowed_scripts_for_private_opac". -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 41742] New: Use of uninitialized value in repeat (x)... warning in acqui-home.pl
by bugzilla-daemon＠bugs.koha-community.org 12 May '26

12 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41742 Bug ID: 41742 Summary: Use of uninitialized value in repeat (x)... warning in acqui-home.pl Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: roman.dolny(a)jezuici.pl QA Contact: testopia(a)bugs.koha-community.org The warning: [WARN] Use of uninitialized value in repeat (x) at /kohadevbox/koha/acqui/acqui-home.pl line 137 appears in the plack-intranet-error.log when entering into Acquisitions module. To reproduce in ktd: 1. Observe plack-intranet-error.log. 2. In staff interface go to Acquisitions module. 3. Warning appears in plack-intranet-error.log. It seems that the "depth" key in: sprintf( "%s", ">" x $$budget{depth} . $$budget{budget_name} ); has not been set previously. Several uses of "depth" are in the "CheckBudgetParentPerm" sub, which is probably not called anywhere. This part of the code is responsible for displaying indents in the list of budgets and funds in the "Fund" drop-down of the Acquisitions module. So maybe it should be the "budget_level" key or "CheckBudgetParentPerm" should be called? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 42329] New: Staff can check out to patrons with fines over NoIssuesCharge when AllowFineOverride set to Don't Allow
by bugzilla-daemon＠bugs.koha-community.org 11 May '26

11 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42329 Bug ID: 42329 Summary: Staff can check out to patrons with fines over NoIssuesCharge when AllowFineOverride set to Don't Allow Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com To recreate: - add fines/fees to a patron account until they are over the limit set by the noissuescharge system preference - confirm AllowFineOverride is set to "Don't Allow" - log into Koha as a user with force_checkout permission (or a superlibrarian) - go to the account of your patron with fines - you are given a warning that the patron cannot check out and has charges on their account, but offered an "Override restriction temporarily" button - click "Override restriction temporarily" - check an item out to your patron successfully If AllowFineOverride is set to "Don't Allow," users should not be able to check out to patrons with fines over the noissuescharge amount, regardless of user permissions. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9