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

[Bug 8137] Checkout limit for all libraries
by bugzilla-daemon＠bugs.koha-community.org 04 Oct '26

04 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8137 Philip Orr <philip.orr(a)lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Needs Signoff --- Comment #170 from Philip Orr <philip.orr(a)lmscloud.de> --- Hi Thibaud, I wanted to try a signoff but the newest addition (203407 - (follow-up) Fix QA test failures) seems to not apply. I get the following: ´´´ Error: Apply failed: Git command (git am -3 /tmp/p44q0MwO5a/0004-203407.patch) failed: error: sha1 information is lacking or useless (Koha/CirculationRules.pm). error: could not build fake ancestor ``` -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 40258] New: Option to only use item-level recalls and disable record-level recalls
by bugzilla-daemon＠bugs.koha-community.org 03 Oct '26

03 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40258 Bug ID: 40258 Summary: Option to only use item-level recalls and disable record-level recalls Change sponsored?: --- Product: Koha Version: Main 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 It would be good to essentially hide the "Recall next available item" options for libraries who do not want record-level recalls -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 43362] New: URI validation for biblio MARC21 field 856$u and items.uri
by bugzilla-daemon＠bugs.koha-community.org 03 Oct '26

03 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43362 Bug ID: 43362 Summary: URI validation for biblio MARC21 field 856$u and items.uri Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Would be nice to add (basic) URI validation for biblio MARC21 field 856$u and items.uri. Opening another report for authority records in relation to the use of external vocabularies, including corresponding biblio subfields. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 43333] New: Restore the name of the vendor as h1 in vendor details page
by bugzilla-daemon＠bugs.koha-community.org 03 Oct '26

03 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43333 Bug ID: 43333 Summary: Restore the name of the vendor as h1 in vendor details page Initiative type: --- Sponsorship --- status: 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- While testing 26.05 prior to rolling it out to our clients, the team noticed that in the vendor's details page, the name of the vendor is not prominent anymore. There is a h2 that says "Vendor #x" but the name of the vendor is only in the small section in the details. For most end users, they don't care that this is vendor #1, #2 or #38. They tell the vendors apart by their name. I can't tell which bug changed this because for some reason vue pages don't react well to git checkout (or maybe I just don't know how it works which is also a possibility). In 25.05.05 which is the version our clients currently use, the vendor name is in an h1. In main (and 26.05.02), the vendor # is in an h2 and, as far as I can tell, there is no h1. To recreate : 1. In KTD, go to Acquisitions 2. Click Search in the vendor search box 3. Click "My vendor" --> The biggest title on the page is "Vendor #1" --> "My vendor" is in the breadcrumbs and in the form, but both are small and a bit lost in the rest of the information 4. Inspect the title "Vendor #1" --> It's a h2 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 43655] New: Authentication by identity provider does not create entry in action_logs
by bugzilla-daemon＠bugs.koha-community.org 03 Oct '26

03 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43655 Bug ID: 43655 Summary: Authentication by identity provider does not create entry in action_logs Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: david_liddle(a)sil.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When using external authentication, specifically a Google OpenID Connect configuration or the same service set up as an OIDC Identity Provider, no entry is added to action_logs when a patron or staff member logs in through the service. For security, auditing, and troubleshooting purposes, the action logs should include such entries. Ideally, the log would identify which authentication method was used, distinguishing between local and external. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 43713] New: Preventing spam blocks
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43713 Bug ID: 43713 Summary: Preventing spam blocks Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Target Milestone: --- I'm wondering, if we had quota limits on how much email could go to each specific email provider in specified time frame, if that would help prevent email servers from blocking for spam from some of the bigger libraries. I've been noticing a Comcast response bounce message: Comcast block for spam So, for example, if we could determine their threshold for this block, could we limit the queue for Comcast emails just below that threshold until, and leave the remainder of the emails in the queue until the next window that they wouldn't ding us? We could have a table of providers that we build over time, particularly from those that gripe about the number of emails going out, and if they exist in the table, those outgoing emails would be throttled by the Koha queue according to whatever time frame we set for that provider. Does that make any sense? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 43712] New: Performance boost on patron search
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43712 Bug ID: 43712 Summary: Performance boost on patron search Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- I notice that when I enter search criteria for a patron, and the suggestions pop up, I will often just press enter rather than use the suggestions, particularly when I see that there is only one result. It looks like when I press enter without choosing it doesn't just load that single result. It looks like Koha starts the search all over again, as if the suggestions didn't happen. I'm wondering if Koha could be made a little smarter, and if there is only one result in the suggestions that it automatically highlights that single entry and loads it rather than redo the search. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 42383] New: Vue-based interface for check-in
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42383 Bug ID: 42383 Summary: Vue-based interface for check-in Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement 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 Depends on: 24401 Bug 36540 proposes a Vue-based interface or checkout. This bug is for a vue-based checkin page. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24401 [Bug 24401] REST API: Check-in -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 37893] New: Migrate some SIP configuration into the staff client
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Bug ID: 37893 Summary: Migrate some SIP configuration into the staff client Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration 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 'accounts' and 'institutions' sections of the SIP Server configuration should be able to be moved into the Koha Staff Client.. this would help librarians understand what settings are in place and allow them to make small changes to those configurations as required. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 144

[Bug 43637] New: Refactor patron image upload into a reusable engine class and background job
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43637 Bug ID: 43637 Summary: Refactor patron image upload into a reusable engine class and background job Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- This patch extracts tools/picture-upload.pl's inline patron image import logic (previously coupled to CGI globals) into a reusable, CGI-free Koha::Patron::Image::Import engine class, and adds a Koha::BackgroundJob::PatronImageImport background job for batch/zip uploads. Single-image upload - including the "Patron photo" modal and webcam capture embedded on every patron's own record page - stays fully synchronous, since that instant "upload and see it now" UX is this tool's most common real-world use and doesn't benefit from being async. Batch/zip upload alone moves to the same two-step AJAX-upload plus background-job pattern tools/import_borrowers.pl already established. Both modes gain a configurable matchpoint (card number, username, or a patron attribute type), replacing the previous hardcoded card-number-only lookup. Batch mode also supports filename-stem matching for zips with no idlink.txt/datalink.txt mapping file - each image is matched by its own filename (minus extension) against the chosen matchpoint directly. Along the way this replaces the original tool's shelled-out unzip and naive path-traversal check with a real Archive::Zip-based extraction and zip-slip guard, and fixes a resize-math bug where oversized images were scaled against stale 140x200 literals instead of the tool's own documented and threshold-checked 200x300 maximum. This is a precursor to a separate, not-yet-filed bug for scheduled/automated patron image import via file transports (mirroring Koha's existing scheduled patron import feature) - that work depends on the engine class this patch introduces, but scheduling itself is out of scope here. Test plan: 1. Apply the whole patchset, update the database if prompted, restart_all. 2. Open any patron's record, use the "Patron photo" modal to upload a file, and confirm it appears immediately (no job, no delay) - then delete it the same way. If a webcam is available, confirm the "Take patron photo" capture flow also still works. 3. Go to Tools > Upload patron images, select "Image file", choose a matchpoint (try username, and a patron attribute type if Extended patron attributes is enabled), type a matching identifier, upload a file, and confirm immediate success. 4. Prepare a zip containing two images and an idlink.txt mapping file using your chosen matchpoint's values, upload it via "Zip file" mode, and confirm you land on a "job enqueued" page; follow its link to view the job and confirm it shows imported/error counts and a progress bar that advances while the job runs. 5. Prepare a second zip with loose images named <identifier>.<ext> and no mapping file; upload it and confirm each is matched by its own filename. 6. Prepare a zip whose idlink.txt has a row pointing outside the archive (e.g. "BADCARD,../../etc/passwd"); upload it and confirm the job's error report shows that row failed safely, with no file touched outside the archive. 7. Prepare a zip whose idlink.txt has one good row and one row using an unrecognized delimiter; confirm the good row imports and the bad row is reported as an error, not silently dropped. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20