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

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

25 Mar '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 1

[Bug 33523] New: Hold Queue targets items on record level holds that should not fill the hold
by bugzilla-daemon＠bugs.koha-community.org 25 Mar '26

25 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33523 Bug ID: 33523 Summary: Hold Queue targets items on record level holds that should not fill the hold Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Holds queue doesn't check if a branch's item can fill the hold if at least one item is available on the record for a bib level hold To recreate: • Have ReservesControlBranch set to "item's home library" • Have at least 2 libraries. • Set the circulation rules so that a patron type can place holds on an item type at library A • Set the circulation rules so that the same patron type cannot place holds on or have any checkouts on the same item type at library B • Make a record with at least 2 items, one at library A and one at library B. • Place a bib level hold for a patron matching the patron type in the rules • Run holds to pull for both branches • The item should only show on Library A's list, but it also shows on library B. Library B doesn't allow checkout of those items for that patron type. The same thing also happens if there are separate item types on the same record, such as a public copy and a staff copy. The staff copy will try to fill the hold even though it can only be held and loaned by staff. Lisette -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 33070] New: Get rid of Koha::Patron->can_edit_item and use can_edit_item_from instead
by bugzilla-daemon＠bugs.koha-community.org 25 Mar '26

25 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33070 Bug ID: 33070 Summary: Get rid of Koha::Patron->can_edit_item and use can_edit_item_from instead Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Bug 20256 introduced a pattern we are trying to avoid for a long time now (old patchset). It should be refactored and cleaned. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 42173] New: add an option to block payment operations for patrons with expired account
by bugzilla-daemon＠bugs.koha-community.org 25 Mar '26

25 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42173 Bug ID: 42173 Summary: add an option to block payment operations for patrons with expired account 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: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Currently, credit can be added to the account of a patron whose account has expired. This can be problematic if the library’s policies restrict paid services to patron whose accounts are active There should be a system setting to prevent this. Or maybe it could be completely blocked, but I suspect some libraries will prefer having the choice. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 23898] New: New data to share on HEA
by bugzilla-daemon＠bugs.koha-community.org 25 Mar '26

25 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23898 Bug ID: 23898 Summary: New data to share on HEA Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul.poulain(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Some ideas of thing that could be shared on HEA for statistics purposes: - adding some statistics like "intranetuserjs yes/no" => yes if there's something, no if it's empty ? (intranetuserjs, opacuserjs, opac & intranet css, opacheader, opacnav, opacbottom). - For sysprefs *XSLT* => we could send "empty/default/local". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[Bug 7376] Transfer limits should be checked at check-in
by bugzilla-daemon＠bugs.koha-community.org 25 Mar '26

25 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7376 Tomás Cohen Arazi (tcohen) <tomascohen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |41728 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41728 [Bug 41728] Add `Koha::Item::Checkin::Availability` to centralize logic -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38924] New: Introduce a loan 'Quota' system for Koha
by bugzilla-daemon＠bugs.koha-community.org 25 Mar '26

25 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38924 Bug ID: 38924 Summary: Introduce a loan 'Quota' system for Koha 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Some libraries work based on the number of allowed issues in a time period as opposed to the number of simultaneous issues. This enhancement intends to add a per-user, including guarantee/guarantor relations, quota option for setting a fixed number of issues a user is allowed within a specified period. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 274

[Bug 30552] New: Add a way to import circulation rules
by bugzilla-daemon＠bugs.koha-community.org 25 Mar '26

25 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30552 Bug ID: 30552 Summary: Add a way to import circulation rules 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com bug 18392 added a method for exporting the circ table, however, that bug originally requested both import/export - opening this to allow import to be explored in the future -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 39541] New: Do we need to store the whole MARC record in Elasticsearch?
by bugzilla-daemon＠bugs.koha-community.org 25 Mar '26

25 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39541 Bug ID: 39541 Summary: Do we need to store the whole MARC record in Elasticsearch? Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: domm(a)plix.at QA Contact: testopia(a)bugs.koha-community.org Currently the whole MARC Record is stored in the ElasticSearch Record. At the Koha Hackfest 2025 I learned that one reason for this is to be able to search the whole record (Bug 22258). Another reason might be to avoid hitting the DB when displaying search results. But: * We sometime encounter problems with very large records (due to limits with UNIMARC) * The code to store the whole record is rather convoluted (involes encoding/decoding the record, checking for errors, falling back to other encoding methods..) * It bloats the ES index (if it's not needed) So I will investigate: * would displaying search results work without the whole MARC record? * aren't we hitting the DB anyway during displaying search results * in OPAC * in Staff * in API If it seems easy to optionally not add the whole record to the index, I would suggest * Adding a new Option "Don't store" to syspref ElasticsearchMARCFormat * If it is set, skip adding the whole MARC -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 32581] New: Update dateexpiry on categorycode change
by bugzilla-daemon＠bugs.koha-community.org 24 Mar '26

24 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32581 Bug ID: 32581 Summary: Update dateexpiry on categorycode change Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: hebah(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If you change a patron's category code, nothing checks whether their existing dateexpiry is valid for their category. An immediate renewal will correct this, but without that step, you could have someone move from a category with longer enrollment into a shorter enrollment period without anything prompting a check if that dateexpiry is still valid. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 48