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

[Bug 41879] New: Holds that move to a new bib can be unfillable
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41879 Bug ID: 41879 Summary: Holds that move to a new bib can be unfillable Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com If a library's 'Holds and bookings policies by item type' allows holds by patrons from any library, but pickup at the item’s home library only, holds can be moved from bib A to bib B in a way that makes them unfillable with no indication that they won't fill. Currently, when the hold is moved from bib A to bib B, the hold pickup location will not automatically update to reflect the rule, and there is no notice that the rule has been broken. Scenario: -ReservesControlBranch is set to 'item's home library' -Main library's 'Holds and bookings policies by item type' for the itype BOOK is set to allow holds from patrons from any library, but pickup at Main only -Bib A is owned by North library, and bib B is owned by Main. Both are the item type BOOK, and each has one item on the bib. Steps: -Place a hold for a North patron on bib A for pickup at North -Move the hold to bib B -Note that the hold moves successfully, and is still set for pickup at North When the hold moves, there is no indication that the item will never trigger to send to North due to Main's 'Holds and bookings policies by item type'. The only way staff would realize that the hold will never fill is if they drop down the pickup locations for the moved hold and see the flag indicating that the current location isn't allowed. The move should either fail (as it does if the target record only allows holds from patrons matching the item’s home library per 'Holds and bookings policies by item type'), or staff should be forced to select a valid pickup location in order to complete the move. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 34

[Bug 41227] New: SuspendHoldsIntranet and SuspendHoldsOPAC have no effect
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41227 Bug ID: 41227 Summary: SuspendHoldsIntranet and SuspendHoldsOPAC have no effect Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: david.roberts(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com It seems that no matter what the SuspendHoldsIntranet and SuspendHoldsOPAC system preferences are set to, the suspend holds column always appears in both the staff client and OPAC. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 41084] New: Zotero connector broken by bug 37370
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41084 Bug ID: 41084 Summary: Zotero connector broken by bug 37370 Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Depends on: 37370 This is difficult.. as I said in the comment on bug 37370, we find libraries don't want to visually show utf8 in the export menu, but do want Zotero to work. As such, completely denying the utf8 option, which is the default fallback when no format is passed too, breaks the Zotero browser extension. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37370 [Bug 37370] opac-export.pl can be used even if exporting disabled -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

[Bug 41061] New: No longer needed to validate dates manually
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41061 Bug ID: 41061 Summary: No longer needed to validate dates manually Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 33703 I've tried to resurrect bug 31149 but finally realised that this code is no longer needed. I think it's coming from the introduction of Masikto by bug 33703. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33703 [Bug 33703] Entering dates should be more flexible accepting different entry formats -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 41204] New: OpenURL ILL no longer defaults to Standard if FreeForm
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41204 Bug ID: 41204 Summary: OpenURL ILL no longer defaults to Standard if FreeForm Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Bug 38288 introduced a compatibility measure to fallback to 'Standard' if provided backend on the URL if 'FreeForm'. This was done in order to not introduced immediate breakage for third-party applications redirecting to Koha through openURL sending backend=FreeForm. Bug Bug 41057 introduced code to present a 404 if the provided backend in the URL is not a valid OPAC backend, preventing ILL requests from being created by visiting the URL directly. This worked, but broke the functionality introduced in 38288, i.e. it now shows a 404 if the backend is FreeForm. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 29587] New: Test mail option in SMTP servers
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29587 Bug ID: 29587 Summary: Test mail option in SMTP servers Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: vimalibre(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Dear Developers, Here is a feature suggestion to Administration > SMTP servers. Test mail option helpful for users to try newly added SMTP server works or not. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 60

[Bug 41425] New: Log entries for merging patrons are untranslatable
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41425 Bug ID: 41425 Summary: Log entries for merging patrons are untranslatable Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: f.demians(a)tamil.fr, jonathan.druart(a)gmail.com Depends on: 22632 Koha/Patron.pm: . " has been merged into " We should never hardcode strings into .pm, they are not translatable. This should be solved on template level instead. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22632 [Bug 22632] Add logging of merged patrons -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 32142] New: Add HoldFeeMode option "if all items are checked out OR the record has at least one hold already"
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32142 Bug ID: 32142 Summary: Add HoldFeeMode option "if all items are checked out OR the record has at least one hold already" 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: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Relates to Bug 31963. There is an option for the HoldFeeMode system preference "only if all items are checked out and the record has at least one hold already", except it behaved more like "if all items are checked out OR the record has at least one hold already". Bug 31963 fixed this so that the behaviour better matches the description i.e. it says 'and' so that implies BOTH conditions must be met. However we now need an option so that the behaviour from before isn't lost, behaviour like "if all items are checked out or the record has at least one hold already" -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 48

[Bug 30295] New: Send a notification when a recall is manually cancelled
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30295 Bug ID: 30295 Summary: Send a notification when a recall is manually cancelled 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: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The process would be: 1. Recall is cancelled by library staff or the requester. 2. Notification of the recall cancellation is sent via email and SMS to the recall requester. So it would be exactly the same as the HOLD_MANUAL_CANCEL notice that we currently have for reserves, only relevant to recalls. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 101

[Bug 42066] New: CSRF-token sometimes missing from pages
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42066 Bug ID: 42066 Summary: CSRF-token sometimes missing from pages Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org To reproduce in KTD: - In your console, keep an eye on the logs: $ sudo tail -f /var/log/koha/kohadev/plack*.log - Open the SCO main page (http://localhost:8080/cgi-bin/koha/sco/sco-main.pl) in your browser, but do not do anything there - Remove the path from the URL, in the address bar of your browser, so you just have http://localhost:8080/, and press enter - Use Ctrl+u or "developer tools" to view the source of the front page, search for "csrf" and verify the elements that should contain the csrf token are empty: <meta name="csrf-token" content="" /> <input type="hidden" name="csrf_token" value="" /> - Log in an verify you get an error like this: Error 403 This message can have the following reason(s): An unexpected error occurred while processing your request. - Check the logs and verify you have an error like this: ==> /var/log/koha/kohadev/plack-opac-error.log <== [2026/03/11 08:12:41] [WARN] Programming error - No CSRF token passed for POST http://localhost:8080/opac/opac-main.pl (referer: http://localhost:8080/) at /kohadevbox/koha/Koha/Middleware/CSRF.pm line 97. Moving from SCO to the main page like this is probably not something that happens too often, but perhaps there is some underlying problem that can also affect other parts of Koha? -- You are receiving this mail because: You are watching all bug changes.

1 24