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

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

02 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8137 David Nind <david(a)davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Needs Signoff --- Comment #166 from David Nind <david(a)davidnind.com> --- (In reply to Mathieu Saby from comment #165) > I am a bit lost. Did we really re-signoff this patch after the last changes > made by Thibaud? I think it needs sign off again. Status changed to "Needs Signoff". -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 29099] New: Add support for item bundles in the inventory tool
by bugzilla-daemon＠bugs.koha-community.org 02 Aug '26

02 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29099 Bug ID: 29099 Summary: Add support for item bundles in the inventory tool Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client 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 I chose to split out the inventory tool additions from the bundles bug.. that bug was already big enough ;) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 50

[Bug 41460] New: On Mysql on upgrade from 25.05 to 25.11 I got the error TEXT column 'value' can't have a default value
by bugzilla-daemon＠bugs.koha-community.org 02 Aug '26

02 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41460 Bug ID: 41460 Summary: On Mysql on upgrade from 25.05 to 25.11 I got the error TEXT column 'value' can't have a default value Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: michael.hafen(a)washk12.org QA Contact: testopia(a)bugs.koha-community.org Mysql does not allow blob or text type columns to have a default. The systempreferences.value column is the only occurrence of this I found in the kohastructure.sql file. It seems Mysql will ignore the default null as long as the column allows null, so that's not an issue. Bug 40405 sets systempreferences.value to NOT NULL, but tries to also add a DEFAULT '', which causes Mysql to throw the above error. Proposed solution is to remove the DEFAULT '' part of the clause from the db_rev file. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[Bug 39637] New: Patron search generates URIs that are too long and can cause "HTTP 414 URI Too Long" errors
by bugzilla-daemon＠bugs.koha-community.org 01 Aug '26

01 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39637 Bug ID: 39637 Summary: Patron search generates URIs that are too long and can cause "HTTP 414 URI Too Long" errors Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Continuation of bug 31104 which did not solve the problem completely. Steps to reproduce: 1. Log in to staff interface 2. In the top search bar, select "Patrons search" and type "a b c d e f g h i j k l m" and submit the form 3. The patrons table should fail to load with a message like this: "Something went wrong when loading the table. 414: Request-URI Too Long.". If the table loads successfully, try adding a few more letters (separated by space) to the search. Another error that can happen is a 5XX error caused by the length of Link headers. Here is the (decoded) URL generated for "a b c d e": http://koha-dev-main/api/v1/patrons?_page=1&_per_page=20&q=[{"-and":[[{"me.firstname":{"like":"a%"}},{"me.preferred_name":{"like":"a%"}},{"me.middle_name":{"like":"a%"}},{"me.surname":{"like":"a%"}},{"me.othernames":{"like":"a%"}},{"me.cardnumber":{"like":"a%"}},{"me.userid":{"like":"a%"}}],[{"me.firstname":{"like":"b%"}},{"me.preferred_name":{"like":"b%"}},{"me.middle_name":{"like":"b%"}},{"me.surname":{"like":"b%"}},{"me.othernames":{"like":"b%"}},{"me.cardnumber":{"like":"b%"}},{"me.userid":{"like":"b%"}}],[{"me.firstname":{"like":"c%"}},{"me.preferred_name":{"like":"c%"}},{"me.middle_name":{"like":"c%"}},{"me.surname":{"like":"c%"}},{"me.othernames":{"like":"c%"}},{"me.cardnumber":{"like":"c%"}},{"me.userid":{"like":"c%"}}],[{"me.firstname":{"like":"d%"}},{"me.preferred_name":{"like":"d%"}},{"me.middle_name":{"like":"d%"}},{"me.surname":{"like":"d%"}},{"me.othernames":{"like":"d%"}},{"me.cardnumber":{"like":"d%"}},{"me.userid":{"like":"d%"}}],[{"me.firstname":{"like":"e%"}},{"me.preferred_name":{"like":"e%"}},{"me.middle_name":{"like":"e%"}},{"me.surname":{"like":"e%"}},{"me.othernames":{"like":"e%"}},{"me.cardnumber":{"like":"e%"}},{"me.userid":{"like":"e%"}}]]},{"-or":[{"me.firstname":{"like":"a+b+c+d+e%"}},{"me.preferred_name":{"like":"a+b+c+d+e%"}},{"me.middle_name":{"like":"a+b+c+d+e%"}},{"me.surname":{"like":"a+b+c+d+e%"}},{"me.othernames":{"like":"a+b+c+d+e%"}},{"me.cardnumber":{"like":"a+b+c+d+e%"}},{"me.userid":{"like":"a+b+c+d+e%"}}]},{"-and":[[{"extended_attributes.value":{"like":"a%"},"extended_attributes.code":[["Nickname","PAT_1"]]}],[{"extended_attributes.value":{"like":"b%"},"extended_attributes.code":[["Nickname","PAT_1"]]}],[{"extended_attributes.value":{"like":"c%"},"extended_attributes.code":[["Nickname","PAT_1"]]}],[{"extended_attributes.value":{"like":"d%"},"extended_attributes.code":[["Nickname","PAT_1"]]}],[{"extended_attributes.value":{"like":"e%"},"extended_attributes.code":[["Nickname","PAT_1"]]}]]}]&_match=contains&_order_by=+me.surname,+me.preferred_name,+me.firstname,+me.middle_name,+me.othernames,+me.street_number,+me.address,+me.address2,+me.city,+me.state,+me.postal_code,+me.country (Ignore the extended_attributes.* params that are not the main issue here, even though they contribute to the problem) If I'm counting correctly, for each word searched, the URL length is increased by (216 + 7 * <word length>) characters (before encoding, which also increases the URI length by a lot). For me, with Apache, the problem happens around 8k characters (after encoding). IMO it would be better to send only parameters like 'search', 'search_type' and 'search_field' to the API and translate this to DBIC dialect on the backend. This would make it a lot harder to reach the limit (and would make the URI far more readable, which is always nice :)) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 51

[Bug 37598] New: Ability to use the BCC field for sending notices to multiple addresses, rather than the To field
by bugzilla-daemon＠bugs.koha-community.org 01 Aug '26

01 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37598 Bug ID: 37598 Summary: Ability to use the BCC field for sending notices to multiple addresses, rather than the To field Change sponsored?: --- 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: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Bug 12802 allows libraries to select a list of email address fields to use when sending notices to patrons. You would check all of the email addresses you want to use in a new system preference EmailFieldSelection and Koha will send the notice to all of those addresses. However, all of those addresses do go through in the To field. They are not in the BCC field. It would be good to enable the option to use the BCC field for the email addresses rather than the To field. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 44

[Bug 42174] New: Elasticsearch throws "Too many clauses" error
by bugzilla-daemon＠bugs.koha-community.org 01 Aug '26

01 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42174 Bug ID: 42174 Summary: Elasticsearch throws "Too many clauses" error Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In ES8 or ES9 in KTD if you search with a lot of terms like: is this too many search terms to search a a single time maybe you get in the logs: [http://es:9200]-[400] [illegal_argument_exception] Query rewrite failed: too many clauses, called from sub Search::Elasticsearch::Role::Cxn::process_response at /kohadevbox/koha/Koha/SearchEngine/Elasticsearch.pm line 56. With vars: {'status_code' => 400,'body' => {'status' => 400,'error' => {'type' => 'search_phase_execution_exception','failed_shards' => [{'reason' => {'reason' => 'Query rewrite failed: too many clauses','type' => 'illegal_argument_exception','caused_by' => {'reason' => 'Query contains too many nested clauses; maxClauseCount is set to 1024','type' => 'too_many_nested_clauses'}},'index' => 'koha_kohadev_biblios','node' => 'o6de3CLcQfmF5HA5oW8QsQ','shard' => 0}],'root_cause' => [{'type' => 'illegal_argument_exception','reason' => 'Query rewrite failed: too many clauses'}],'reason' => 'all shards failed','caused_by' => {'caused_by' => {'type' => 'illegal_argument_exception','reason' => 'Query rewrite failed: too many clauses','caused_by' => {'reason' => 'Query contains too many nested clauses; maxClauseCount is set to 1024','type' => 'too_many_nested_clauses'}},'reason' => 'Query rewrite failed: too many clauses','type' => 'illegal_argument_exception'},'grouped' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),'phase' => 'query'}},'request' => {'method' => 'GET','ignore' => [],'serialize' => 'std','body' => {'query' => {'bool' => {'must' => [{'query_string' => {'lenient' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),'query' => '(is* this* too* many* search* terms* to* search* a* a* single* time* maybe*)','fuzziness' => 'auto','analyze_wildcard' => $VAR1->{'request'}{'body'}{'query'}{'bool'}{'must'}[0]{'query_string'}{'lenient'},'type' => 'cross_fields','default_operator' => 'AND','fields' => ['music-key','number-local-acquisition','title-collective','date-entered-on-file','ln-audio','stack','author','lf','author-name-corporate','rtype','cn-bib-source','local-number','title-former','datelastseen','name-geographic','datelastborrowed','control-number-identifier','cn-sort','issues','identifier-other','date-time-last-modified','host-item','number-db','materials-specified','biblioitemnumber','issn-all','coden','price','lc-card-number','totalissues','publisher','author-title','geolocation_lon','identifier-publisher-for-music','personal-name','bgf-number','language-original','issn','cn-suffix','lost','author-personal-bibliography','title-other-variant','reserves','musical-presentation','title-expanded','ln','subject-name-personal','uri','ff7-01-02','itemtype','restricted','editor','ff8-29','barcode','itype','llength','lc-call-number','author-in-order','geolocation_lat','material-type','microform-generation','title-uniform','bnb-card-number','record-control-number','nal-call-number','stock-number','curriculum','coded-location-qualifier','code-geographic','identifier-standard','author-name-personal','title-cover','name','code-institution','number-govt-pub','renewals','interest-age-level','homebranch','cross-reference','damaged','acqsource','interest-grade-level','index-term-uncontrolled','ff7-01','extent','index-term-genre','thematic-number','ln-subtitle','itemnumber','bib-level','isbn','copynumber','not-onloan-count','date-of-acquisition','koha-auth-number','title-series','arp','title-later','nlm-call-number','copydate','current-publication-frequency','date-of-publication','classification-source','ctype','title-no-punctuation','name-and-title','map-scale','number-legal-deposit','cn-bib-sort','bio','number-natl-biblio','cn-prefix','withdrawn','related-periodical','dewey-classification','cn-class','ta','holdingbranch','record-source','ff8-23','abstract','ff7-00','cn-item','title','replacementprice','local-classification','corporate-name','report-number','dissertation-information','note','location','other-control-number','control-number','udc-classification','reading-grade-level','notforloan','ccode','su-geo','indexed-by','host-item-number','replacementpricedate','subject','title-key','title-abbreviated','arl','geographic-class','provider','pl','isbn-all','lexile-number','conference-name','ff7-02']}}],'should' => [{'match' => {'title-cover' => {'query' => 'is this too many search terms to search a a single time maybe'}}}]}},'size' => '20','aggregations' => {'itype' => {'terms' => {'field' => 'itype__facet','size' => '20'}},'homebranch' => {'terms' => {'field' => 'homebranch__facet','size' => '20'}},'location' => {'terms' => {'field' => 'location__facet','size' => '20'}},'su-geo' => {'terms' => {'size' => '20','field' => 'su-geo__facet'}},'ccode' => {'terms' => {'size' => '20','field' => 'ccode__facet'}},'author' => {'terms' => {'size' => '20','field' => 'author__facet'}},'title-series' => {'terms' => {'size' => '20','field' => 'title-series__facet'}},'holdingbranch' => {'terms' => {'size' => '20','field' => 'holdingbranch__facet'}},'ln' => {'terms' => {'size' => '20','field' => 'ln__facet'}},'subject' => {'terms' => {'size' => '20','field' => 'subject__facet'}}},'sort' => [{'_score' => {'order' => 'desc'}},{'local-number' => {'order' => 'desc'}}],'from' => 0},'qs' => {'track_total_hits' => 'true'},'path' => '/koha_kohadev_biblios/_search','mime_type' => 'application/json'}} Checking ES documentation it seems both the way clauses are calculated and the limit have changed -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 41285] New: ERM: Agreements are missing space before and after options
by bugzilla-daemon＠bugs.koha-community.org 01 Aug '26

01 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41285 Bug ID: 41285 Summary: ERM: Agreements are missing space before and after options Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Created attachment 189894 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=189894&action=e… screenshot of table with agreement When looking at the list of agrements, there is a filter on top of the table. This filter section is missing some whitespace around and before options, as shown in the screenshot. -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 11999] Add two checks in CanBookBeReserved and CanItemBeReserved
by bugzilla-daemon＠bugs.koha-community.org 01 Aug '26

01 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11999 David Nind <david(a)davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Text to go in the|This fixes placing holds |This fixes placing holds release notes|when using ILS-DI - the |when using ILS-DI. The |value set in maxreserves |value set in maxreserves |(for example 1) was |system preference (for |ignored, and you could |example 1) was ignored, and |place more holds than |you could place more holds |maxreserves. |than maxreserves. | | |Note: When placing holds |Note: When placing holds |using the OPAC or staff |using the OPAC or staff |interface, the value set in |interface, the value set in |maxreserves is taken into |maxreserves continues to |account. (That is, you |work as expected. (That is, |can't place more holds than |you can't place more holds |what is set in maxreserves |than what is set in |using the OPAC or staff |maxreserves using the OPAC |interface.) |or staff interface.) Status|Needs Signoff |Failed QA --- Comment #147 from David Nind <david(a)davidnind.com> --- Apologies that it took me so long to retest. Updates to test plan when using KTD (see comment 143): 1. Step 2 - with 0.0.0.0/0 or ::/0 in ILS-DI:AuthorizedIPs system preference, I get Unauthorized IP address errors. Changed it the IP address that was shown. 2. Step 7 should be: Try to place another hold using ILS-DI: - Hold 4 (Higher-order Perl): http://127.0.0.1:8080/cgi-bin/koha/ilsdi.pl?service=HoldTitle&patron_id=19&…'127.0.0.1' Still getting test failures: prove t/db_dependent/Reserves.t - passes if I increase the number of tests to 72 prove t/db_dependent/Holds.t t/db_dependent/Holds.t .. 1/74 # Failed test '$branch_1 patron allowed to reserve $branch_2 item with IndependentBranches OFF (bug 2394)' # at t/db_dependent/Holds.t line 280. # got: 'tooManyReserves' # expected: 'OK' # Failed test '... unless canreservefromotherbranches is ON (bug 2394)' # at t/db_dependent/Holds.t line 295. # Failed test 'Patron can reserve damaged item with AllowHoldsOnDamagedItems enabled' # at t/db_dependent/Holds.t line 349. # got: 'tooManyReserves' # expected: 'OK' # Failed test 'Patron can place hold on item that is not for loan but holdable ( notforloan < 0 )' # at t/db_dependent/Holds.t line 387. # got: 'tooManyReserves' # expected: 'OK' # Failed test 'can request item if we are not checking holds counts, but only if policy allows or forbids it' # at t/db_dependent/Holds.t line 431. # got: 'tooManyReserves' # expected: 'OK' # Failed test 'cannot request item if policy that matches on item-level item type forbids it' # at t/db_dependent/Holds.t line 449. # got: 'tooManyReserves' # expected: 'noReservesAllowed' t/db_dependent/Holds.t .. 52/74 # Failed test 'cannot request item if policy that matches on item-level item type forbids it even if ignoring counts' # at t/db_dependent/Holds.t line 453. # got: 'tooManyReserves' # expected: 'noReservesAllowed' # Failed test 'A biblio-level hold already exists - another hold can be placed on a specific item item' # at t/db_dependent/Holds.t line 628. # got: 'tooManyReserves' # expected: 'OK' # Failed test 'A biblio-level hold already exists - another hold can be placed on a specific item item' # at t/db_dependent/Holds.t line 628. # got: 'tooManyReserves' # expected: 'OK' # Failed test 'A item-level hold already exists and holds_per_record=1, another hold cannot be placed on this record' # at t/db_dependent/Holds.t line 658. # got: 'tooManyReserves' # expected: 'tooManyHoldsForThisRecord' # Failed test 'A item-level hold already exists and holds_per_record=1 - tooManyHoldsForThisRecord has priority over tooManyReserves' # at t/db_dependent/Holds.t line 673. # got: 'tooManyReserves' # expected: 'tooManyHoldsForThisRecord' # Failed test 'A item-level hold already exists but holds_per_record=2- another item-level hold can be placed on this record' # at t/db_dependent/Holds.t line 688. # got: 'tooManyReserves' # expected: 'OK' # Looks like you failed 5 tests of 7. # Failed test 'tooManyHoldsForThisRecord + tooManyReserves + itemAlreadyOnHold' # at t/db_dependent/Holds.t line 719. # Looks like you failed 1 test of 2. # Failed test 'CanItemBeReserved' # at t/db_dependent/Holds.t line 720. # Failed test 'CanItemBeReserved should return 'notReservable'' # at t/db_dependent/Holds.t line 760. # got: 'tooManyReserves' # expected: 'notReservable' # Failed test 'CanItemBeReserved should use PatronLibrary rule when ReservesControlBranch set to 'PatronLibrary'' # at t/db_dependent/Holds.t line 769. # got: 'tooManyReserves' # expected: 'cannotReserveFromOtherBranches' # Failed test 'CanItemBeReserved should use item home library rule when ReservesControlBranch set to 'ItemsHomeLibrary'' # at t/db_dependent/Holds.t line 775. # got: 'tooManyReserves' # expected: 'OK' # Failed test 'CanItemBeReserved should return 'OK'' # at t/db_dependent/Holds.t line 782. # got: 'tooManyReserves' # expected: 'OK' # Failed test 'Patron can reserve item if checking policy but not counts' # at t/db_dependent/Holds.t line 829. # got: 'tooManyReserves' # expected: 'OK' # Failed test 'Patron can place hold with no borrower circ rules' # at t/db_dependent/Holds.t line 877. # got: 'tooManyReserves' # expected: 'OK' # Failed test 'Patron can place hold with branch/category rule of 5, category rule of 3' # at t/db_dependent/Holds.t line 898. # got: 'tooManyReserves' # expected: 'OK' # Failed test 'Patron can place hold with branch/category rule of 5, category rule of 5' # at t/db_dependent/Holds.t line 918. # got: 'tooManyReserves' # expected: 'OK' # Looks like you failed 3 tests of 6. # Failed test 'Test max_holds per library/patron category' # at t/db_dependent/Holds.t line 919. t/db_dependent/Holds.t .. 63/74 # Failed test 'Patron can reserve item with 2 reserves daily cap' # at t/db_dependent/Holds.t line 1050. # Structures begin differing at: # $got->{status} = 'tooManyReserves' # $expected->{status} = 'OK' # Failed test 'Patron cannot a third item with 2 reserves daily cap' # at t/db_dependent/Holds.t line 1065. # Structures begin differing at: # $got->{limit} = '1' # $expected->{limit} = '2' # Failed test 'Patron can reserve item with 2 bib level hold placed on different days, 2 reserves daily cap' # at t/db_dependent/Holds.t line 1076. # Structures begin differing at: # $got->{status} = 'tooManyReserves' # $expected->{status} = 'OK' # Failed test 'Patron can reserve if holds_per_day is undef (i.e. undef is unlimited daily cap)' # at t/db_dependent/Holds.t line 1136. # Structures begin differing at: # $got->{status} = 'tooManyReserves' # $expected->{status} = 'OK' # Failed test 'Unlimited daily holds, but reached reservesallowed' # at t/db_dependent/Holds.t line 1149. # Structures begin differing at: # $got->{limit} = '1' # $expected->{limit} = '3' # Failed test 'Unlimited daily holds, but reached reservesallowed' # at t/db_dependent/Holds.t line 1157. # Structures begin differing at: # $got->{limit} = '1' # $expected->{limit} = '3' # Looks like you failed 6 tests of 10. # Failed test 'CanItemBeReserved / holds_per_day tests' # at t/db_dependent/Holds.t line 1164. t/db_dependent/Holds.t .. 68/74 # Failed test 'Patron of specified category can place 1 hold on specified itemtype if library rule for all types and categories set to 2' # at t/db_dependent/Holds.t line 1820. # Structures begin differing at: # $got->{status} = 'tooManyReserves' # $expected->{status} = 'OK' # Looks like you failed 1 test of 3. # Failed test 'CanItemBeReserved rule precedence tests' # at t/db_dependent/Holds.t line 1828. t/db_dependent/Holds.t .. 71/74 # Looks like you failed 16 tests of 74. t/db_dependent/Holds.t .. Dubious, test returned 16 (wstat 4096, 0x1000) Failed 16/74 subtests Test Summary Report ------------------- t/db_dependent/Holds.t (Wstat: 4096 (exited 16) Tests: 74 Failed: 16) Failed tests: 33, 35, 38, 43, 50-57, 60, 62, 64, 69 Non-zero exit status: 16 Files=1, Tests=74, 8 wallclock secs ( 0.03 usr 0.01 sys + 5.98 cusr 1.43 csys = 7.45 CPU) Result: FAIL -- You are receiving this mail because: You are watching all bug changes.

1 0