https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42164 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42164 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |paul.derscheid@lmscloud.de -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42164 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nick@bywatersolutions.com --- Comment #1 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- We need to implement normalization for authorities to provide the correct forms used for linking, and also implement linking We need to implement 'See from' inclusion in records Browse functionality would be nice, or 'scan' as in zebra We should introduce a new pluggable/flexible template for processing search results that we can then port ES to, rather than continuing to build on the original Zebra only base and adding exceptions (kill C4::Search) -- 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=42164 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fridolin.somers@biblibre.co | |m -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42164 --- Comment #4 from David Cook <dcook@prosentient.com.au> --- (In reply to Nick Clemens (kidclamp) from comment #1)

We need to implement normalization for authorities to provide the correct forms used for linking, and also implement linking

Normalization is such a loaded word, eh? This talks about normalizing authorities but it's for normalizing them in the database schema sense not the search sense: https://github.com/HKS3/koha-normalize-marc2db/blob/main/Koha/Plugin/HKS3/No... That said, I have a memory from Kohacon of Mark talking about this... Looking at https://github.com/HKS3/koha-nm2db-keyword-search/blob/main/Koha/Plugin/HKS3... I can see the addition of a FULLTEXT INDEX and the use of MATCH(), but I guess that's also in a search sense rather than a MARC search sense... Because with Zebra/Elastic it's not just that we're indexing the MARC data... but we index it in particular ways I think. And speaking of authorities... yeah how would this database search handle linked bibs? By searching all subfield $9? Very interesting -- 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=42164 --- Comment #6 from Mark Hofstetter <mark@hofstetter.at> --- Created attachment 204516 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204516&action=edit Bug 42164: Allow plugins to provide search engines This patch adds the minimum core integration needed to test alternative search engines without putting a proof-of-concept implementation directly into Koha core. Enabled plugins can register Search, QueryBuilder, and Indexer classes through a koha_search_engine method. The SearchEngine system preference then offers the built-in Zebra and Elasticsearch engines together with the engines registered by plugins. The database-backed reference implementation is: https://github.com/HKS3/koha-nm2db-keyword-search It currently depends on normalized MARC tables provided by: https://github.com/HKS3/koha-normalize-marc2db Database architecture and security ---------------------------------- A database-backed search engine also exposes a broader architectural issue. This concerns the MariaDB service account, not a Koha staff or patron account. A standard Koha instance uses one database identity from koha-conf.xml for its normal DBI/DBIx connections, and the Debian installation grants that identity ALL PRIVILEGES on the instance database. The OPAC, staff interface, background workers, command-line tools, upgrades, reports, and plugins consequently use the same highly privileged database identity. The same schema also contains primary records, configuration, denormalized/generated data, transient state, and plugin-owned tables. Koha already keeps some caches and indexes outside MariaDB through Memcached and Zebra/Elasticsearch, so this is not a claim that all cache data is stored in the main database. The limitation is the lack of a general way to assign different connections, schemas, credentials, and data lifecycles to different components. Additional database identities could improve security through least privilege: * An OPAC identity could have SELECT access to public catalogue and availability data, no access to unrelated administrative or acquisition tables, and narrowly scoped write permissions for enabled patron operations such as holds, renewals, suggestions, tags, and account updates. It would not have DDL privileges. It cannot be completely read-only because several OPAC features legitimately write data. * A reports identity could be read-only, ideally against allowlisted views or a read replica so that sensitive patron, authentication, and financial columns can be excluded or masked. * A staff runtime identity could have the DML rights needed for normal staff work but no CREATE, ALTER, or DROP privileges. * A migration identity could hold DDL rights and only be available during installation and upgrades. * Search engines and plugins could use component-specific identities and, where appropriate, separate schemas containing rebuildable data. This would reduce the impact of a compromised OPAC, plugin, or report: the compromised component would not automatically gain access to every table or be able to change the schema. It would also improve auditability and credential rotation. Database permissions would supplement, not replace, Koha's application authorization. The attached patch does not introduce multiple database connections. It makes the search layer extensible so the database-search approach can be evaluated first. Named connections and documented privilege profiles would be a possible follow-up, while retaining the current single-account setup as the compatibility default. Test plan --------- 1. Apply the attached patch to current master and enable Koha plugins. 2. Run: prove t/Koha/SearchEngine.t 3. Confirm Administration > System preferences > SearchEngine still contains Zebra and Elasticsearch. 4. Install and enable the latest NormalizeMARC2DB plugin, then use "Run tool" once to normalize the existing bibliographic and authority records. 5. Install and enable the NM2DBKeywordSearch reference plugin. 6. Return to the SearchEngine preference. Confirm DBSearch is now offered and select it. 7. Search in both the OPAC and staff catalogue. Verify result pages, facets, refinements, year limits, and pagination. 8. From a Koha shell, run the reference comparison test: prove -v /path/to/koha-nm2db-keyword-search/t/nm2db_vs_koha_search.t 9. Disable the NM2DBKeywordSearch plugin and confirm DBSearch is no longer offered as a preference choice. Switch back to Zebra or Elasticsearch before testing normal searches. The reference integration test compares the database-backed result sets with Koha's normal keyword search for representative terms and also checks facets, search-within-results, availability, publication-year limits, and pagination. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.