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

[Bug 42593] New: Add ability for background reports ( and saved reports ) output to be stored on the filesystem instead of the database
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42593 Bug ID: 42593 Summary: Add ability for background reports ( and saved reports ) output to be stored on the filesystem instead of the database 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Reports can output any amount of data which is now currently stored in the database. It seems like a good idea to be able to store that output on the filesystem instead of in the database. Maybe with a syspref for "never/always/ask" or something along those lines. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 43116] New: Repeatable Settings Not Retained When Updating Subfield Order in Frameworks
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43116 Bug ID: 43116 Summary: Repeatable Settings Not Retained When Updating Subfield Order in Frameworks Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: PC OS: Windows Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: mspinney(a)clamsnet.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Created attachment 202192 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202192&action=e… Shows the incorrect repeatable settings for MARC Tag 376 after subfields 4 and i were moved The repeatable settings for subfields in frameworks do not update correctly after dragging and dropping them into a new order. This could cause data loss if a subfield is improperly kept as not repeatable. Koha should only update a subfield's repeatable setting when it's edited. To recreate: 1. View the constraints column for the specific MARC tag in the framework you are about to edit, e.g. MARC21 Update 41 from Bug #41702. Note which subfields are repeatable and which are not repeatable. 2. Add the new subfields and save. Note that the new subfields have been appended to the bottom of the list, and all repeatable settings are still correct in the constraints column. 3. Drag and drop the new subfields into the appropriate order and save. 4. View the constraints column again and note which subfields are repeatable and which are not. Notice the repeatable settings are no longer correct. 5. Fix the repeatable settings for all affected subfields and save. Check the constraints column again and confirm the repeatable settings have been properly retained. The attached screenshot shows the incorrect repeatable settings after $4 and $i were dragged and dropped for MARC tag 376. $4, $d, and $i should be repeatable and $6, $s, and $t should not be repeatable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 42373] New: Add ability to disallow unbounded patron api searches
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42373 Bug ID: 42373 Summary: Add ability to disallow unbounded patron api searches Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com In a Koha instance with multiple hundreds of thousands of patrons, a patron api search with _per_page=-1 can cause a single worker to query the database for all patrons, then query the database multiple times for each of those patrons to decorate the resulting patrons ( fees owed, etc ). If the _per_page size is greater than the limit we specify, Koha should refuse the request and emit an http status code 400, with a clear error body explaining the max allowed _per_page value. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 37

[Bug 41048] New: Add ability to disallow empty patron searches
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41048 Bug ID: 41048 Summary: Add ability to disallow empty patron searches Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com In high traffic environments with large numbers of patrons, empty patron searches can take a very long time and cause over-use of resources. It would be good to have the option to require search criteria for patron searches. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 58

[Bug 37541] New: Changing PIN after turning on forced PIN reset results in setting of NEVER
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37541 Bug ID: 37541 Summary: Changing PIN after turning on forced PIN reset results in setting of NEVER Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: chanel.wheeler(a)yavapaiaz.gov QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org We set up a new patron category with an expiration date of 90 days. We then moved the shared staff accounts over to this new category and set a manual expiration date of a few weeks out. We then went into one of these staff accounts and manually changed the PIN. Now on the patron detail page, it shows their PIN Expires as NEVER. It should show either the manual expiration date we'd already set, or a new date 90 days out. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 41750] New: ForcePasswordResetWhenSetByStaff prohibits login via CAS
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41750 Bug ID: 41750 Summary: ForcePasswordResetWhenSetByStaff prohibits login via CAS Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org When ForcePasswordResetWhenSetByStaff is set to "enforce" and staff adds creates a new patron account, login by CAS is impossible. It took us a while to figure this out, since it just "won't work" without any helpful error message. I think there are different ways this could be handled. We could not check the password expiration date if a user authenticates through another external system (LDAP, CAS, OAuth2), since they cannot change the password then. The smallest solution might be warning on the pref, to not enable this for patron categories that use external authentication. I think in general it would be nicer to allow external authentication and still enforce if local login is used - there might be cases where both are the same patron category now and this would keep things more flexible. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 43599] New: auth_val_cat.sql should be updated for is_integer_only column
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43599 Bug ID: 43599 Summary: auth_val_cat.sql should be updated for is_integer_only column Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- Bug 27512 added is_integer_only column but we don;t update the defaults in auth_val_cat.sql. The following is_system categories should be is_interger_only = 1 +---------------+-----------+-----------------+ | category_name | is_system | is_integer_only | +---------------+-----------+-----------------+ | DAMAGED | 1 | 1 | | LOST | 1 | 1 | | NOT_LOAN | 1 | 1 | | RESTRICTED | 0 | 1 | | STACK | 0 | 1 | | WITHDRAWN | 1 | 1 | +---------------+-----------+-----------------+ -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 41646] New: Self-checkin displaying too much whitespace due to incorrect HTML
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41646 Bug ID: 41646 Summary: Self-checkin displaying too much whitespace due to incorrect HTML Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org There's some incorrect HTML which is causing a lot of whitespace to appear on http://localhost:8080/cgi-bin/koha/sci/sci-main.pl which looks very broken -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 41144] New: Fix markup errors in self checkout and self checkin templates
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41144 Bug ID: 41144 Summary: Fix markup errors in self checkout and self checkin templates Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Self checkout Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 21266 The W3C HTML validator complains of a number of minor issues in the self checkout and self checkin templates which should be addressed. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21266 [Bug 21266] Missing doc-head-close and cssinclude in sco-main.tt -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 43602] New: Add REST API endpoints for article request status transitions
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43602 Bug ID: 43602 Summary: Add REST API endpoints for article request status transitions 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: martin.renvoize(a)openfifth.co.uk QA Contact: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com Target Milestone: --- Currently the REST API only exposes cancellation for article requests: - DELETE /api/v1/article_requests/{article_request_id} (Koha::REST::V1::ArticleRequests#cancel) - DELETE /api/public/patrons/{patron_id}/article_requests/{article_request_id} (#patron_cancel) Every other step of the article request lifecycle is missing from the REST API and instead goes through the legacy cookie-authenticated CGI script svc/article_request (op=cud-process|cud-pending|cud-complete|cud-update_urls|cud-update_library_id), called from koha-tmpl/intranet-tmpl/prog/js/fetch/article-request-api-client.js: - Set request as pending (Koha::ArticleRequest->set_pending, status -> PENDING) - Process request (Koha::ArticleRequest->process, status -> PROCESSING) - Complete request (Koha::ArticleRequest->complete, status -> COMPLETED) - Update delivery URL(s) for SCAN format requests (the urls column) - Update pickup library (the branchcode column) There is also no REST endpoint to create an article request (Koha::ArticleRequest->request), used by opac/opac-request-article.pl and circ/request-article.pl. This means there is no documented/stable way to drive the article request fulfilment workflow (the staff queue at circ/article-requests.pl) programmatically via API key/OAuth2 - only cancellation is covered by the documented API. Suggested scope: 1. POST /api/v1/article_requests (and/or a nested /api/v1/biblios/{biblio_id}/article_requests) to create a request 2. PATCH /api/v1/article_requests/{article_request_id} to support status transitions (pending/processing/completed) and updates to urls/branchcode, reusing the same authorization (circulate: circulate_remaining_permissions) as the existing cancel route 3. An equivalent public route under /api/public/patrons/{patron_id}/article_requests for OPAC self-service creation, mirroring the existing patron_cancel route Filling this gap would let svc/article_request be retired in favour of the REST API, and let koha-tmpl/intranet-tmpl/prog/js/fetch/article-request-api-client.js move off the legacy endpoint, consistent with Koha's move away from ad hoc svc/ scripts. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7