https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lisette@bywatersolutions.co | |m -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mark@hofstetter.at --- Comment #1 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- We've had some discussion about this at the hackfest and there were some concerns about patron privacy among other things. Can you share more about this and the status? Will it be optional? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomascohen@gmail.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 --- Comment #3 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Putting patron data on another server with other data if you are using a separate Elasticsearch cluster raises questions at least for privacy documentation but also for other means: is the connection secure/encrypted, is the data kept separate, who can access it etc. I think it's not "could" - it's _must_, because as you say, Elasticsearch is not mandatory. But if we have to maintain another option anyway, I think it makes sense to also have a switch for libraries using Elasticsearch to opt-out of patron search via Elasticsearch. Maintaining 2 separate ways of doing things not always serves us well, because there will be feature differences and extra work included. I wonder if we should not thoroughly investigate improving the SQL based search first. I believe Mark had already identified some of the issues with it. It could turn out some simpler tweaks can already get us a long way. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42643 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42643 [Bug 42643] [OMNIBUS] Assorted performance and stability work -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 --- Comment #6 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- *** Bug 42682 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 --- Comment #7 from David Cook <dcook@prosentient.com.au> --- I thought that I commented on this previously... I'm with Mark on this one. I think this is a job that the database can still tackle. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #8 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Hi all, I'm going to submit what I've implemented for ES patron indexing and searching. It is a drop-in replacement for the current search page with the same functionality, plus the infrastructure required to keep the index up to date. Much of the work is relevant for an SQL-based implementation too, and I'll explore that next. I would like to mention that the Koha dev community has not endorsed migrating logic from the application layer into database triggers in the past (see bug 33905), and I believe the reasons still hold. Triggers make the denormalized search table always-on and DB-local, but they also move patron business logic into opaque synchronous database side effects. For high-traffic circulation systems, that can increase write-path latency, amplify locking, introduce deadlocks, and make bulk updates/imports harder to reason about. I prefer an explicit async indexing path: patron-affecting business actions enqueue indexing jobs, and a full rebuild tool guarantees recoverability. That said, I'll talk to ByWater about investing some time in trying the denormalized table approach with the framework I've already built. If the denormalized table is maintained by the same async indexing framework, rather than triggers, it avoids most of the operational concerns around hidden synchronous database side effects. At that point, the tradeoff becomes less about safety and more about search capability: SQL materialization is simpler to deploy, while Elasticsearch provides a more capable search backend (ranking, fuzziness, analyzers, partial matching, etc). -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 --- Comment #9 from Mark Hofstetter <mark@hofstetter.at> --- Most of the opinions about database triggers seem a little outdated to me. Anyway I implemented a working plugin, if people like it can be integrated easily into koha as well. We dont have any customers with "many" patrons so for us/me it's not that relevant. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 --- Comment #10 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Created attachment 199540 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199540&action=edit [DO NOT PUSH] Bug 42508: 1.5M patron generation script for perf testing Inserts 1.5M patrons with extended attributes directly via DBI for performance testing the ES patron search at scale. Usage: perl t/lib/generate_patrons.pl -v [-c count] [-b batch_size] [-i] -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 --- Comment #12 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Created attachment 199542 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199542&action=edit Bug 42508: Add ES patron indexing infrastructure Adds the indexing layer for ES patron search: - Patron field mappings YAML (patron_mappings.yaml) - Indexer module (Koha::SearchEngine::Elasticsearch::Indexer::Patrons) - Background job for async patron indexing (UpdateElasticPatronIndex) - CLI tool for index management (misc/search_tools/es_patron_index.pl) - Indexing hooks on Koha::Patron and Koha::Patron::Attribute Test plan: 1. Apply patch 2. Run: $ ktd --shell k$ prove t/Koha/SearchEngine/Elasticsearch/Indexer/Patrons.t \ t/db_dependent/Koha/SearchEngine/Elasticsearch/Indexer/Patrons.t => SUCCESS: Tests pass! 3. Sign off :-D -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 --- Comment #14 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Created attachment 199544 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199544&action=edit Bug 42508: Add patron search UI with ES backend Adds the user-facing patron search page: - members/patrons.pl controller with query param passthrough - patrons.tt template with full UI parity to the original: - Sidebar search form (fieldset.brief pattern) with category/library dropdowns - Toolbar (Select all, Clear all, Add to list, Merge, Batch mod) - Browse by last name letters - Search description display - DataTables with column filter dropdowns via kohaTable dataFilter - Async overdues loading (spinner -> fetch per patron) - Escaped output via escape_str(), format_price() for fines - Transparent redirect from member.pl and members-home.pl when enabled - Header search box wired to patrons.pl with syspref-aware autocomplete - patron_autocomplete source-url option for ES-backed suggestions Test plan: 1. Apply patch 2. Enable ElasticsearchPatronSearch syspref 3. Navigate to Patrons => Redirects to the new ES-powered search page 4. Search, filter by library/category, browse by letter => Results display correctly with proper styling 5. Sign off :-D -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 --- Comment #16 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- (In reply to Mark Hofstetter from comment #9)

Most of the opinions about database triggers seem a little outdated to me.

Fair enough, and I agree modern MariaDB/MySQL capabilities are much better than they used to be. My concern is less about triggers being inherently bad technology, and more about where we want patron indexing/search materialization logic to live long-term in Koha, especially considering imports, background jobs, plugins, upgrades, and high-concurrency circulation workflows. I think there is probably room for both approaches here: * SQL materialization for simpler deployments; * Elasticsearch for more advanced search capabilities and larger installations. What I would really like to avoid is duplicating indexing/update logic in multiple places. If we can converge on a shared async indexing/materialization framework, different backends could coexist much more cleanly. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #199540|0 |1 is obsolete| | Attachment #199541|0 |1 is obsolete| | Attachment #199542|0 |1 is obsolete| | Attachment #199543|0 |1 is obsolete| | Attachment #199544|0 |1 is obsolete| | Attachment #199545|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 --- Comment #19 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Created attachment 199579 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199579&action=edit Bug 42508: Add system preferences for Elasticsearch patron search Patch from commit 937ed3e -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 --- Comment #21 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Created attachment 199581 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199581&action=edit Bug 42508: Add patron ES search query builder and REST API Adds the search layer: - Koha::SearchEngine::Elasticsearch::Search::Patrons query builder - Honors DefaultPatronSearchFields syspref - Supports starts_with and contains match types - Column-level filters with colon-separated multi-field OR search - Facet aggregations for library, category, and restriction status - REST API endpoint GET /search/patrons with DataTables compatibility - Autocomplete endpoint GET /search/patrons/autocomplete Test plan: 1. Apply patch 2. Run: $ ktd --shell k$ prove t/Koha/SearchEngine/Elasticsearch/Search/Patrons.t \ t/db_dependent/api/v1/search_patrons.t => SUCCESS: Tests pass! 3. Sign off :-D -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 --- Comment #23 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Created attachment 199583 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199583&action=edit Bug 42508: Add ES reindexing triggers for patron data changes Enqueues patron ES reindexing when related data changes: - Koha::Checkout: reindex on checkout/return (checkouts_count) - Koha::Account::Line: reindex on account line changes (account_balance) - Koha::Library: reindex all patrons when library name changes - Koha::Patron::Category: reindex all patrons when category description changes - Koha::AuthorisedValue: reindex patrons when AV descriptions change (for extended attributes backed by authorised values) Test plan: 1. Apply patch 2. Run: $ ktd --shell k$ prove t/db_dependent/Koha/Checkout.t \ t/db_dependent/Koha/Account.t \ t/db_dependent/Koha/Patron/Category.t \ t/db_dependent/AuthorisedValues.t => SUCCESS: Tests pass! 3. Sign off :-D -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 --- Comment #25 from David Cook <dcook@prosentient.com.au> --- I just don't understand what the exact pain point is with the current search. 1.5 million rows in a database isn't much. I just searched an unindexed field on a PostgreSQL table with 24.5 million rows and it took 1-2 seconds. PostgreSQL is a superior database system, but still. In a non-Koha app, I have a PostgreSQL table with over 600,000,000 rows. That can be tricky but there's ways of working with that in terms of indexes as well. I know that there has been an issue with search - possibly patron search - in the past where we were searching an unindexed field and I think that one was solved by adding an index. Rather than switching from the database to Elastic, why don't we try to look at the actual problems/root causes? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 --- Comment #27 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- (In reply to David Cook from comment #26)

Doing a quick scan of the comments... I think the issue is the extended patron attributes because they are stored in a normalized format in the database.

Yeah sometimes denormalising is the right answer for performance. I've done that in the past using DB triggers, but another option is using an ORM software trigger. I mean we already override store() methods, so that's trivial.

Look at the code I provided and the things I index. All the software triggers we need are implemented in it. I’ll take a look at making an SQL driver using a denormalized table this week. As I said, there are tradeoffs here, but the design allows adding a DB backend easily. There’s a lot of analysis and the code i submitted is the result of many iterations. Please look at it. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 --- Comment #29 from David Cook <dcook@prosentient.com.au> --- (In reply to Tomás Cohen Arazi (tcohen) from comment #27)

Look at the code I provided and the things I index. All the software triggers we need are implemented in it.

I’ll take a look at making an SQL driver using a denormalized table this week. As I said, there are tradeoffs here, but the design allows adding a DB backend easily.

There’s a lot of analysis and the code i submitted is the result of many iterations. Please look at it.

I'll send you a DM -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 --- Comment #31 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- The problem I have here is that a lot of work went into code before a discussion about it happened. I commented here, Tomas was not even aware of this bug. It's a problem of communication and now that there is code already there is pressure for it to be included as a lot of work went into it. I would have preferred to have some discussion beforehand. As pointed out before, the data itself is even for big consortia not enough to really impress the DBMS, so there is probably something weird we are doing in our queries or data structure. The other thing is that we would have to support 2 parallel patron search systems forever if this goes in. And historically we are not very good at that. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 --- Comment #33 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- (In reply to Tomás Cohen Arazi (tcohen) from comment #32)

drivers only where needed. But beware there are outstanding issues around patron search that are not just performance ones, but no fuzzy searching, no attribute boosting, no typo tolerance, etc. All of those can be dramatically benefited from searching in ES alone.

My original implementation included facetted filtering too, but it was too radical for a change, so I made it just be the exact same UI for now. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 --- Comment #35 from David Cook <dcook@prosentient.com.au> --- (In reply to Tomás Cohen Arazi (tcohen) from comment #32)

So maybe the useful next step is to discuss the desired architecture first:

* fix the current SQL queries/data structure directly; * introduce a denormalized SQL search projection; * make patron search pluggable; * or support Elasticsearch as an optional backend.

The code I submitted is meant to inform that discussion, not bypass it.

That sounds reasonable to me :) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 --- Comment #36 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Created attachment 199621 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199621&action=edit Bug 42508: Add system preferences for Elasticsearch patron search Patch from commit 937ed3e -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 --- Comment #38 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Created attachment 199623 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199623&action=edit Bug 42508: Add patron ES search query builder and REST API Adds the search layer: - Koha::SearchEngine::Elasticsearch::Search::Patrons query builder - Honors DefaultPatronSearchFields syspref - Supports starts_with and contains match types - Column-level filters with colon-separated multi-field OR search - Facet aggregations for library, category, and restriction status - REST API endpoint GET /search/patrons with DataTables compatibility - Autocomplete endpoint GET /search/patrons/autocomplete Test plan: 1. Apply patch 2. Run: $ ktd --shell k$ prove t/Koha/SearchEngine/Elasticsearch/Search/Patrons.t \ t/db_dependent/api/v1/search_patrons.t => SUCCESS: Tests pass! 3. Sign off :-D -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 --- Comment #40 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Created attachment 199625 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199625&action=edit Bug 42508: Add ES reindexing triggers for patron data changes Enqueues patron ES reindexing when related data changes: - Koha::Checkout: reindex on checkout/return (checkouts_count) - Koha::Account::Line: reindex on account line changes (account_balance) - Koha::Library: reindex all patrons when library name changes - Koha::Patron::Category: reindex all patrons when category description changes - Koha::AuthorisedValue: reindex patrons when AV descriptions change (for extended attributes backed by authorised values) Test plan: 1. Apply patch 2. Run: $ ktd --shell k$ prove t/db_dependent/Koha/Checkout.t \ t/db_dependent/Koha/Account.t \ t/db_dependent/Koha/Patron/Category.t \ t/db_dependent/AuthorisedValues.t => SUCCESS: Tests pass! 3. Sign off :-D -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 --- Comment #42 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Created attachment 199627 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199627&action=edit Bug 42508: Support index-specific ES server configuration This patch allows configuring a dedicated Elasticsearch server for the patrons index via the existing <elasticsearch> block in koha-conf.xml: <elasticsearch> <server>127.0.0.1:9200</server> <index_name>koha_instance</index_name> <patrons_server>patron-es:9200</patrons_server> </elasticsearch> Changes: - Constructor reads config once and stores it on the instance - Checks for <{index}_server> key (e.g., patrons_server) to override nodes - get_elasticsearch_params returns stored config without re-reading - Falls back to <server> when no index-specific server is configured Test plan: 1. Apply patch 2. Run: $ ktd --shell k$ prove t/Koha/SearchEngine/Elasticsearch/Indexer/Patrons.t => SUCCESS: Tests pass! 3. Verify existing ES biblio/authority search works unchanged 4. Optionally add <patrons_server> to the <elasticsearch> block 5. Rebuild patron index => SUCCESS: Uses the separate server 6. Sign off :-D -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42743 Blocks| |42744 Attachment #199621|0 |1 is obsolete| | Attachment #199622|0 |1 is obsolete| | Attachment #199623|0 |1 is obsolete| | Attachment #199624|0 |1 is obsolete| | Attachment #199625|0 |1 is obsolete| | Attachment #199626|0 |1 is obsolete| | Attachment #199627|0 |1 is obsolete| | Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42743 [Bug 42743] Support dedicated ES server for the patrons index https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42744 [Bug 42744] Add Database backend for patron search (denormalized table) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 --- Comment #45 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Created attachment 199784 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199784&action=edit Bug 42508: Add ES patron indexing infrastructure Adds the indexing layer for ES patron search: - Patron field mappings YAML (patron_mappings.yaml) - Indexer module (Koha::SearchEngine::Elasticsearch::Indexer::Patrons) - Background job for async patron indexing (UpdateElasticPatronIndex) - CLI tool for index management (misc/search_tools/es_patron_index.pl) - Indexing hooks on Koha::Patron and Koha::Patron::Attribute Test plan: 1. Apply patch 2. Run: $ ktd --shell k$ prove t/Koha/SearchEngine/Elasticsearch/Indexer/Patrons.t \ t/db_dependent/Koha/SearchEngine/Elasticsearch/Indexer/Patrons.t => SUCCESS: Tests pass! 3. Sign off :-D -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 --- Comment #47 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Created attachment 199786 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199786&action=edit Bug 42508: Add patron search UI with ES backend Adds the user-facing patron search page: - members/patrons.pl controller with query param passthrough - patrons.tt template with full UI parity to the original: - Sidebar search form (fieldset.brief pattern) with category/library dropdowns - Toolbar (Select all, Clear all, Add to list, Merge, Batch mod) - Browse by last name letters - Search description display - DataTables with column filter dropdowns via kohaTable dataFilter - Async overdues loading (spinner -> fetch per patron) - Escaped output via escape_str(), format_price() for fines - Transparent redirect from member.pl and members-home.pl when enabled - Header search box wired to patrons.pl with syspref-aware autocomplete - patron_autocomplete source-url option for ES-backed suggestions Test plan: 1. Apply patch 2. Enable ElasticsearchPatronSearch syspref 3. Navigate to Patrons => Redirects to the new ES-powered search page 4. Search, filter by library/category, browse by letter => Results display correctly with proper styling 5. Sign off :-D -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 --- Comment #49 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Created attachment 199788 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199788&action=edit Bug 42508: Ensure ES deletion precedes DB deletion on patron removal Patron deletion must remove personal data from the ES index before removing it from the database. If the ES deletion fails (e.g., ES is unreachable), the entire operation is aborted to prevent personal data from being removed from the DB while remaining searchable in ES. This is relevant for GDPR-like compliance: a patron's right to erasure cannot be partially fulfilled. The full data lifecycle is covered: - Anonymize: patron.store() triggers ES reindex with scrambled data - Delete: ES deletion must succeed before DB deletion proceeds In batch scenarios (cleanup_database.pl), each patron deletion is independent. If ES is down, all deletions fail with a clear error, ensuring no data is removed from the DB without first being removed from all data stores. Test plan: 1. Apply patch 2. Enable ElasticsearchPatronSearch 3. Stop Elasticsearch 4. Attempt to delete a patron => FAIL: Deletion blocked with clear error message 5. Start Elasticsearch 6. Attempt to delete the same patron => SUCCESS: Patron removed from both ES and DB 7. Sign off :-D -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pedro.amorim@openfifth.co.u | |k -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=39637 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42958 Depends on|42958 | Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42958 [Bug 42958] Expand Elasticsearch/Opensearch usage across Koha beyond bibliographic search -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Strategic theme|--- |Performance Target Milestone|--- |26.11 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Initiative type|Feature |Epic -- You are receiving this mail because: You are watching all bug changes.