# Koha Hackfest 2026 Notes These are just my personal notes made by @krimsonkharne/ philip orr, and I am not a developer, these are simple notes... Please correct me if I missed something or misunderstood something or anything. :) and feel free to add! ## Clustering Koha Talking about clusters e.g. Elastic cluster. Bywater not looking for bigger clusters because difficult to know in advance when elasticsearch will go down, speed problems, etc. systems can be scaled out by externalizing search, externalizing sip etc., but it makes the instance slow. It is probably better to solve performance hitting problems (like overdue.pl being so huge and looping through every single overdue) than to worry about clustering. Bywater has pretty big Koha instances and they’re not having huge issues yet. Everyone is interested to see what the turkish libraries are doing since it’s such a huge scale. Nobody really sees a reason to have Koha in a cluster and scalable. It’s more a question on what is causing problems. Splitting into multiple services would help with that since then you can say “oh SIP went down” or “oh a worker from Koha is stuck” or whatever. ## ElasticSearch Thomas: has some things he wants to discuss about ES. He heard ES doesn’t want to provide Perl libraries anymore because there are apparently not enough Perl users of ES. See https://github.com/elastic/elasticsearch-perl/issues/220 One thing we as a community could do is talk to ES and explain that actually we do have a lot of Perl ES users. Otherwise somebody from us has to step up and implement the ES perl libraries (which shouldn’t be very hard). A lot of perl projects (for instance metacpan) also use ES, in two weeks there is a perl summit in Vienna where Thomas will also discuss with them if there is someone who wants to do something anyway. First place to start is to talk to ES. Victor and Tomás have volunteered to do the maintaining the libraries if necessary. Martin / ashimema was volunteered to write a mail to ES. If he says no, Nick volunteers instead. There is a wiki page with recommendations for tweaking ES settings. Some libraries with millions of records need a long time for indexing. Bywater has some libraries not happy with the relevance of things in ES. It used to be that you could set up multiple searches that happen for each query (so search for “exact title” at the same time and so on. But the more of those you do, the more expensive it is) Biblibre has been doing some work on the facets to allow searching multiple values for the same index. So for instance on the OPAC search: when you want to refine your search, you click a facet. But you cannot click multiple of the same facet’s values at the same time. There is a punctuation filter in bug 21537. In Bug 21357 (different bug), shown how to filter elisions for different languages. Clarified: if the field has "searchable" and "opac searchable" both checked, it will be in the keyword search. Not checking both boxes means it isn't in the keyword search, but still can be searched directly as the index. I noted that you can use ```ti.phrase:(perl)``` to do an exact search to find the title "Perl", but not the title "Perl Magic" or "Perl and other things" (it's not exactly the exact search from Zebra but maybe solves the problem) If you have an OpenSearch Cluster there are Options to make the reindexing faster. You could disable replication and refreshing the Index every second while indexing. This is possible with the following commands: before indexing: ``` curl -u <username>:<password> -XPUT "https://opensearch-cluster/koha_<instanzname>_prod_biblios/_settings" \ -H 'Content-Type: application/json' \ -d '{"index":{"number_of_replicas":0,"refresh_interval":"-1"}}' ``` after indexing: ``` curl -u <username>:<password> -XPUT "https://opensearch-cluster/koha_<instanzname>_prod_biblios/_settings" \ -H 'Content-Type: application/json' \ -d '{"index":{"refresh_interval":"1s","number_of_replicas":1}}' ``` ## Identity Providers Martin / ashimema: showed a mockup of Identity Provider definition and configuration in the Koha UI. goal is to get keycloak working with ktd properly so all the identity providers can all be in one system. Goal is so there is the same configuration in the UI (atm different levels of what can be synced, different attributes that they match on.. etc.). Also able to authenticate to different servers and also able whether you are in the opac or in the staff interface. Also be able to give default values. Writtein vue. It is basically the same fields so far, but in Vue. ability to have different hosts where you can set up for one URL there is shibboleth / SSO and for another URL there isn’t. Attribute mapping, default values for ldp field to koha field, sync settings. This will allow the librarians to do things like setting it up or switching out certificates themselves. However maybe plack will need to be restarted. Security bug, so can’t check the bug. 39224 What to do: Jacob needs help testing. He is working on getting SAML set up in ktd for testing e.g. Shibboleth. CAS support is not yet set up in ktd for Keycloak, but you can still test it through Keycloak, you “just” need to get Keycloak set up and configured yourself. ## ILS-DI & restful webservice ## Joubu’s 2026 main works https://chat.koha-community.org/koha-community/pl/pdaeb8sfgi8fmr6jg9nm4iwp5o Joubu has been working on new coding guidelines, changes to dev workflow and wants to advertise 2 plugins. He has been working on Test::NoWarnings: No new warnings are generated from tests. We want to ensure tests don’t generate warnings (so then warnings are only generated if the test is wrong or Koha is wrong). For script tags in the codebase, he is running prettier on JS code to help catch syntax errors and other errors. We are separating isolating TT and JS variables to make code more robust and maintainable and so we can future use .js files. We want to have predictable refactoring, so cleaning up the script tags prevents unexpected large diffs later on. Without this the tidy script might accidentally reformat script Tags (prettier) when only a TT line was removed, this was a problem for devs. Omnibus: Bug 41323. last week pushed 41324 which tidies all kohaTable script blocks. We should no longer add TT tags in script tags. Instead we move the TT Interpolation to a separate script tag and then later on use them in the main script tag. See the bugs for more details. Coming up next month. DataTables: upgraded to 2.3.7. Fix for column visibility bugs. We need to use bKohaColumnsUseNames EVERYWHERE so the column visibility is finally done correctly. Bug 41604 needs signoff and QA. We need to merge the current state of visibility (from local storage) with what the table visibility settings are set up. Also some other stuff, use Select2 for filters, use pageLength=-1 when paginate is false, replace dom with lavout Cypress tests / Plugins: so far it was painful to mock the route and responses. We want a way to generate JS objects and insert into the DB. See Bug 40174. Using Cypress plugins, with mockData.js we can build JS objects based on OpenAPI schema definitions. With insertData.js we can insert them into the DB. Also insertSampleBiblio, insertSampleCheckout etc etc. THese are tasks that you give to cypress when it is run. e.g. cy.task(“insertSampleBiblio”)… etc. Also now allows using API endpoints e.g. patron delete and so on. This way we don’t need to mock DB for a bunch of tables and everything. Incremental test runs instead of 3 hour long test runs. Incremental means we are only testing the files we are taking from the previous run and files modified by recent patches. Reduces to 1 hour. (actually back to 2 hours now ) everyone can use it. We only need this if our tests fail. So if we want to prove for ourself, pass KOHA_CI_INCREMENTAL_RUNS=1 prove xt/perltidy.t Fixing circular dependencies was a crazy problem. It depends on when 2 packages depend on each other in a cycle. Like A depends on B B depends on C C depends on A… We need to fix this soon. It’s a nightmare to fix. It causes performance issues and makes some of our modules too big and doing too many things in memory. It would make everything much less complicated. So how to fix? We need to split up the large modules like C4::Context. See 41890. For instance for checking a syspref: Koha::Context::SystemPreferences instead of calling C4::Context which has all of Koha. Joubu needs people to discuss with him about it. Reworking/Cleaning sys prefs: The code was a mess. for instance not all syspref with “yes/no” were 1/0. Lots of the sysprefs were duplicated in DB and in the YAML files, not needed - removed! ALso wants to discuss autocomplete in syspref search. Next work needed: SO, QA, push! We also need a flag in the DB if a syspref is coming from Koha or is a local use syspref. Also some questions: When do we update the systempreference_explanations table? How do we deal with parent/grouped sysprefs? Do we want to load all sysprefs and filter on clientside (probably no?) Koha now has an own module for the “search for data inconsistencies” script! It shows an alert if a table breaks showing “error 500: have a look at the audit bar.” and in the audit bar (in the staff interface UI for instance it will show: “Item is missing home library” or something). We could put an entire biblio audit script into a background job on the “About koha” page. or we can have an entire new page Audit in the administration area. Automatic Screenshots: we are at 10% validated (about). Last year we discussed the similarity check. We need more. Manual search: using TypeSense? Requires typesense server. See merge request (koha manual gitlab !1169) Joubu has created a server for testing purposes. But we need to decide on a more permanent solution. Doc team will talk about it. “koha-plugin-jump”: It’s a nice way to generate data. https://gitlab.com/joubu/koha-plugin-jump has a UI in Koha to generate test data! Built in perl. And to perform simple actions like checkout/checkin/make 42 patrons with random fields, make holds etc. Alt-G to open the module and use commands. **AWESOME!!! Use it in KTD!** Easy to add more things to for creating more actions / build stuff / etc. For me TODO: maybe add a version of build patrons with umlaut, sonderzeichen and etcetc? Koha Plugin: koha-plugin-ask-the-manual: gives immediate access to koha documentation and tries to use the koha search. Adds direct links from Normierte Werte and sysprefs, book icon that redirects to the correct syspref / authvalue. Also alt-K to open the manual typesense search in Koha itself. Documentation team should make sure to always use the same label as the syspref id / authvalue id, then it would be easier to map the links. Built nightly. Not everybody should use this because it’s also on joubu’s testing typesense server. Content Security Policy: gives an http header to the browser to say: only allow scripts that are coming from either me myself or from a specified URL. Meaning even if there is an XSS vulnerability, it can be blocked by the browser. This means all of our scripts tags need to have the “nonce” tag going forward. Make sure xt/find-missing-nonce.t passes. Next is Bug 38407: all things like onclick, onchange etc. (event handlers) have to be removed. A big problem because people need to adjust the plugins or local customizations. See joubu’s bug list in the presentation for what he needs help with (last slide). (mostly test, QA, push bugs) ## Refactor database translations ## Splitting up xslt Lisette mentioned bug 39860, which allows custom template toolkit of a MARC recorde's fields. Added to the bottom of the xslt block. **LMSCloud: solves our cutom display stuff probably.** Also includes results pages. for 25.11. needs documentation! I'll look at it (Philip) and make a documentation submission to the manual about it. hks3 has been separately working on splitting up xslt structure. bug 40972: adds plugin hook for MARC field display. there are preferences to move away from xslt for record detail pages. it seems performance issues wouldn't be so bad for single record display. **unrelated but very good:** see https://help.bywatersolutions.com/portal/en/kb/articles/data-availability-via-template-toolkit-per-notice-slip for help finding out which tt objects are named what! ## Support ‘diff’ field for all actionlogs (Lisette) See dependency graph for Bug 37940. Should the diff column be on by default? It can be turned on default in the table settings configuration. Permissions changes are now logged in action logs! There is a new “diff” column in the actions logs tables in the Koha UI. It now shows exactly which permission was changed and who changed it! It’s a diff and only shows what changed, not what else is in the fields that didn’t change. Lisette has some scripts to restartall, DBIC etc. see https://github.com/lisettebws . Changed PW also shows up now in the action logs. Modifying item records are in actionlogs and also now have the diff field. Bib records also, it even shows which marc field exactly changed and how.. this means reports are now much easier to check when something changed in action logs. the diff is a JSON that you can check easily. ## Ergonomy of big tables (example patron categories, items...) Laurence was speaking about tables in the UI that break over to the right of the screen in a not nice way, such as the patron category table. When you are on the right side of the screen, you don't see which rule you are working on either. **What to do about it?** - have the actions buttons always in the first few columns? - make it configurable which columns are fixed? Like in table configuration in admin, saying "itype and homebranch are fixed and come with to the right when I scroll right" - not speaking about circulation rules right now, will talk about it later. but that is a possibility for actions buttons to be both at the start and at the end of the table - scrollbar inside the table: we can use table responsive from bootstrap, that makes it so that the right-left scrollbar is only inside the table and not in the browser. - When filters are displayed over the items table, the filter dropdowns will be exactly as long as the longest string, which is usually long. An idea would be to line break the longer strings to reduce the width of the field; or only display the values of the items table and not all possible values in the dropdown. Not so easy since you need to do a second request on the table to see which items are currently displayed. Would require API routes. Same problem in the item search results. - only show values linked to the library displayed? - Possibility to define the fixed width you want in the table confiugration? - Possibility to define which fields in the opac mobile view will be displayed when the items table is too long and gets "cut" (so which fields are displayed without you having to click on the + symbol) Laurence will create tickets to see what is possible. ## AI : how to write koha plugin using ```claude.ai``` * AI Report Assistant * AI Notices Editor * cerulean - Web-based data migration toolkit based on Silverstripe and PHP-ETL https://github.com/bywatersolutions/cerulean ## Bibframe POC : working on it ## ```Bs-community.biblibre.com``` infra It was decided to move to mailman list for the koha mailing lists. It wasn't seen as a big problem that the old links wouldn't work, since the archive would still be searchable. Katipo wants to switch the server by next week. So we have 24 hours to decide what exactly to do. There was also some discussion around who will be root on the new servers for hosting some biblibre koha resources. Also a proposal from Indranil to manage the server. A majority vote decided to move to mailman, Paul (P.) will write a mail about it. ## Circulation rules redesign bugs 41439, 15522, 33312 about the poor display of the circ rules table. also need to make the export/print view better. there is also a bug to make tabs for the display of certain fields. and to be able to configure the table. also bug 19037 with testing circ rules possibility. We want column filters for each tab. Joubu will look at it and put it on Martin's patch (but we should open a bug for it!) BTW, the reason the entire page is reloaded every time a rule is changed is because the table is not over the API but using the old methods. This will probably change at some point, but it's not trivial. Also the save/clear buttons line should be fixed to always display, otherwise you always have to scroll all the way down.. ## ERM Usage / Schedule harvesting of COUNTER statistics – a case study + Plugin KIT wanted to talk about usage of ERM as it is something German libraries need to provide in their yearly German library statistics. Counter in ERM is something like a loan count for printed materials, but since it's electronic it needs to be taken from the ebook/ejournal provider. KIT has a link to the title statistics on the biblio record page that populates a bar graph showing usage for that record. There are different reports counting different usage statistics for different types of electronic media. Providers: Summary page of providers has no distinction between report types, no way to see if a report was harvested successfully. KIT plugin provides a better view. Koha has a background job for each report type that starts the harvesting. Bug 42088 to fix missing indexes in DB. Provider data should overwrite values in Koha, not add to it. **Don't use the yearly usage data! Only the monthly usage data table is currently correct!** Reports in the UI in the ERM usage section are actually also not working correctly. Bug 41306: the harvesting schedule can be selected as a date, but the harvesting always processes the entire month. So the date has no function. There's a flatpickr plugin to allow month selection. Also all report types are always harvested. It would be nice to be able to say you only want to harvest specific report types. Bug 42129 It should be possible to run all harvestings by a single button rather than going through point for point. There is also a cron job to run harvesting, erm_run_harvester KIT Plugin: ErmHarvestingManagement. Made in 24.11. Only works if you do monthly harvesting! Adds some views for errors, harvests, runs etc Errors are visible in the GUI if you have a look at the detail view of the background job. payload_too_large means the response is more than 16MB. can be redefined. Error 3030 = 0 usages. For retries: we need a hook for running a job after a background job is run. Tomas mentioned if we are planning on dropping rabbit, it will be easier to schedule background jobs to be run at set points. https://gitlab.com/kit-library/koha-plugin-erm-harvesting-management Pedro suggests opening a bug about the "yearly" problem, then we can decide if we delete it if nobody needs it. ## ERM usage improvements Notes from Jonathan Field from the ERM usage session Bugs: Yearly Usage table Consolidate monthly into Yearly occasionally (e.g. annually?) - Replace Yearly reports with Monthly Views of the year Harvesting Twice doesn't overwrite if the data changed Data Providers table is slow to load (last run date?) - Missing index on tables (42088) 3030 code & no_items error Harvester UI month picker. Ability to do multiple months Enhancements: Update Data Summary page - see screenshots from presentation Expand ERM Counter logs table to match KIT View tables (replace plugin table) Harvest all (Run ALL) Separate background jobs per month ## Koha PODs ## Long overdue configuration in the UI See below about the overdue notice triggers. ## Natural language search (AI) https://github.com/liliputech/koha-plugin-llmsearch/ ## Overdue notice triggers based on item type Chloe demoed the new UI for the circulation triggers to trigger notices based on circulation rules (library, patron category, itemtype). It now requires the permission for circ rules, not for overdue notice triggers. The circulation triggers are now in the administration page under "Patrons and circulation". The display can be filtered to show either "all applied rules" or only "default values" You can also filter by library, patron category and item type to find the rules quicker. It now has as many "steps" or "overdue levels" or "delays" as you want! You can't delete the next step or "Trigger" if the previous trigger exists (can't delete Trigger 3 if there's a Trigger 2). The display should only show: 1. the default number of triggers set up as a default rule. 2. if you select a library, the number of triggers set up for that library Chloe is improving the scripts / rewriting them to make improvements for the performance and to check the order the rules are applied in (so for instance to solve the problem that the fine is charged after the notice is created, meaning you can't have information about the fee in the notice). Also includes moving the longoverdue rules from the circ table into the triggers table. The triggers setup is in production at Open Fifth for 2 years now, so there is real life experience :) **What to do:** - how do we migrate people who had the overdue notice triggers permission but not the administrations permissions? - Nick pointed out it's not a good idea to raise permissions through migration, better to lower permissions. - There were open questions about permissions through the API. But anyway it makes more sense to move the rules to the administration. - KIT will be testing the migration process of already existing rules to new triggers. - there was a bit of talk about making overdue notices in the patron messaging preferences configurable with the library being able to define e.g. notices that always have to be print or email - I'll add a signoff on 10190 ## Performance/Speed ## Acquisitions refresh There is a group of 7-8 people working on the ACQ module. The group gave a short update on what they are working on. There is a sandbox but it isn't quite working properly in all the places. Michaela also wanted to show the migration plugin KIT has created. A mockup for the future ACQ start page was shown. In the future the administration part will stay in the acquisitions module, not jump to sysprefs. The workflow no longer uses a basket to get started, you jump directly into the orderlines and the basket or "Purchase Order" is created later. But both ways are also still possible in the future. Starting with a definition of if the order is continuous (meaning like an order for a serial subscription, not for an item). Otherwise it is "one-time". Acquisition method was added in case you want to say if the item was a purchase or a gift. You can set acqcreateitems per order line now in case you want to create items on receiving for a single order line. Otherwise the radio button would be populated by the syspref. The framework for new titles would stay ACQ. There is a new section for library management to say a different branch would manage this order. Since you start with the order, you choose the vendor directly in the order, you don't need to start from the vendor search. Vendor is also no longer a required field, but if you leave it empty, you can save the order only as a draft, not as an actual order. In the accounting section it is now possible to use an exact amount for discount instead of percentage, also there is now a fund distribution to use several funds for the same orderline. **Fund splitting will be solved! Finally!** :) Reporting information section has a possibility to show statistic fields, but those statistic fields cannot be tied to funds. So they used for auth values or other things, but not anymore to funds. Possibility to mark orders as urgent / to be rushed! It's only for information purposes, it doesn't do anything else. But helpful to search for. Receiving note is a note that is displayed when you receive (for instance if you are buying media for a certain project, show that it's part of the project when it gets delivered by the vendor so that it is processed separately to "normal" orders). All new VueJS options now have more options for the save button. In this case you can save and continue working on the order or save and return to result list or to save as a draft. Fiscal periods were removed from the budget definition and put in their own administration area. They are only for the date range and contain no other info (besides the managing library and libraries that are using this fiscal period.) You can define library groups to use in the acquisition module. In the fiscal period you can add ledgers. Ledgers are what we in the old days called budgets, so a definition of how much spend limit and connection to which libraries are managing and which are allowed to use this ledger (inherited from the fiscal period). Fiscal period + ledger = "how we currently do budgets" Funds are added to ledgers similarly to how they were added to budgets. The restrict option for restricting access should be able to take the existing installation's setting. But it should also be possible to combine it to the library group access. Receiving wasn't shown yet, but the idea and schema was designed to allow separate reception of orders. More to come on that later. So the idea is you can process the invoice separately from the item. **KIT has a migration plugin for migrating from old ACQ system to new reworked ACQ system:** https://gitlab.com/kit-library/koha-plugin-acq-migration-test But it requires Koha >= 24.11 ! **Only use it in test environments, not in production!** All it does it migrates the data from the old tables to the new tables (so then you can select from them with reports / sql to see what it looks like). Just do SELECT * from acq_budget_overview for the comparison between new and old. Especially good to test if you have a library that has been using ACQ for a long time... :-) Michaela asks people to try it out and please tell her if there are errors or problems anywhere. It would be helpful for KIT to know about possible problems they might have missed. Currently the team is aiming for 27.11. Any development support anyone can contribute would be gratefully received! Get in touch with Open Fifth about it. At the moment we are just focusing on not losing functionality, any improving functionality ideas would be nice to do later on because otherwise it makes everything take longer. ## AI code of conduct https://wiki.koha-community.org/wiki/Coding_Guidelines#.5BDRAFT.5D_AI_and_LLM-assisted_contributions ## BZ Driven Crowdfunding Proposal ## How to hotfix bugs in VueJS modules in production? Vue files need to be build (they are build on package level) To hotfix Vue files: * Check out Koha in the same Version in ktd, do a yarn build and copy files from template/js/Vue/dist/ (?) directory or: * Install CI to rebuild package with one click Needs documentation in the Wiki Paul (D.) will write about it on the wiki. DONE - https://wiki.koha-community.org/wiki/Hotfixing_Vue_Bugs_in_Production We need some examples of companies CI processes. ## ILL Lending (ISO) Pedro is building a new module as part of the existing ILL module and hooking it into circulation. When you enter the ILL function, you start with the configured widgets for the ILL dashboard, so it could be the orders, but it could be something else as well. You see borrowering and lending on the left side. So you can see both passive and active ILL tables from the dashboard. The ILL Lending is about a different library making a request for my Koha library and me fulfilling that request. So there is a difference between Koha as a Requesting Agency and Koha as a Supplying Agency, we want to have a Koha library request from a Koha system, we have to have both parts. The ISO18626 standard defines how it works e.g. which messages the libraries send to each other. That is the scope of the changes made here. For supplying, a hold is placed on an item or on a biblio and it takes the requesting library as the patron held to. This causes the "ExpecttoSupply" status meaning the requesting library knows we will expect to be able to supply the request. In the checkout table, the supplied ILL shows it is an ILL request that was supplied. It then has status Loaned. Once it was returned the loan is completed and the book can be sent back. In Koha the supply ILL just basically redirects to the circulation side. You still set up Koha patrons, they are also defined in the ILL module as a requesting agency. So you need to do both. Currently all descriptions or names are exactly from ISO standard, it will be cleaned up in the future to make e.g. status of an ILL request or reason for a change readable and translatable. Pedro just needs an easy way to know where exactly he is in the process. **Important for LMSCloud:** This will make many big changes to the way the legacy ILL system in Koha works. We'll need to look at it so we can evolve our ALV / RLV / SLNP / PFL systems. On an unrelated discussion, everyone is interested in adding more widgets, making them pluggable, adding reports to widgets etc. More on that "soon" (maybe kohacon) ## KOCT Currently authenticating to Koha is problematic. Matts thinks it might be related to bug 38327. Similar problems have been noted by LMSCloud: you need to have opened Koha staff interface in a different tab in the same browser session while configuring KOCT for the configuration to actually take effect. Martin will look at it and think about it. LMSCloud / Paul D. made a port of KOCT for chrome, which strangely works fine, even though it still does show the authentication error in the configuration page. But at least it actually works while firefox just fails. ## Mana-kb redesign ## Old init move to systemD ## Permission management revamping : dev/test/QA bug 20813 bywater has a proposal for a redesign. there are many problems with permissions we need to solve. the proposal is for a RBAC (role based access control) approach. uses user-role-action-scope system. so it would be much easier to visualize what exactly you need to set up who can do exactly what to which things where. still need to go through every object and think about which object needs which possible actions. example naming convention: patrons:read:own_library need to think about how to add future permissions into already existing roles. suggestion to use the debug mode in koha to show which permissions would be required for which actions on the czrrent opened page. Michaela will send Lisette the mappings she has already done for acq rework. it would be good if acq rework could be used as an example first implementation of the new permissions system. joubu suggests it woulds be easier to migrate only the permissions themselves first and then build the roles later in top. so you don't need two systems running at the same time. it will be 'fun' to test since you have to check all the possible permissions combinations. ## Plugin store : having it functional & running Bug 35837 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35837 Last year as a community we were already talking about it. There is a demo you can check out. The plugins can be installed and updated from the UI! Open Fifth has made a Plugin Store app. The plugin store page in Koha also shows when plugins can be updated. The store fetches the 5 latest releases from Github and shows the most recent. It's planned to push automatically the newest release to the plugin store, at the moment it's done manually over the Plugin Store website. The authors of the plugins would put their plugins on the Open Fifth website at the moment. It's planned to have some moderation in place later on to check plugins that were entered. At the moment Open Fifth must make accounts for people to enter their plugins. In the future it's planned to check Github authentication to allow Plugins to be put in the store. The idea is to have one single plugin store. There are some open questions around moderation, if there is e.g. a possibility for an "allowlist" on the Koha end or similar. Pedro needs people to work on it! **What To Do:** check the things in the bug. There is a list of things that need work on in the comments of the bug. Open Fifth is happy to host it for the community. If anyone has thoughts on data security, where it is hosted, etc., get in contact with Open Fifth. ## View notices and print them ## Improve handling of MARC Save ## Location limits in itemsearch : precise what the libraries need ## Project infrastructure ## Remove more stuff from C4/ ## Report results in data tables (Plugin) available on GitHub and was posted in Mattermost development channel mid of february https://chat.koha-community.org/koha-community/pl/e7s17yk3rpr9ucuumkbbu7xzuc Markus was in KIT Library for internship and worked on this Plugin. KIT is using it in production (Koha 24.11) https://github.com/mpathy/KohaDatatables4Reports ## Deprecation of MS Basic Auth ## Keycloack authentication in KTD / Bug 40596 Identity Providers ## Natural language search (AI) https://github.com/liliputech/koha-plugin-llmsearch/ ## Plugin for publishing repositories ## RAM consumption of 25.11 ## Your first Koha plugin in 10 minutes - one click eye-candy edition with(out) AI. Goal is to make an online tool to create a plugin without much thinking. :) Koha plugin generator kohaplugin.nuantio.com The form is already filled out with everything you need to create a plugin. Just enter the fields, click download and you get the .kpz file! Very easy! Currently only for JS and CSS. If you want to do more complicated things with Perl, you probably need Paul(D.)'s plugin. ## Zebra : deprecating ? Reason to have Zebra is because for small libraries, it is easier and more efficient than Elasticsearch. There are some functionalities it would be nice to have in Koha. Can we replace Zebra with something else? There are other small search enginges that could be a replacement drop-in instead of Zebra, for instance Typesense. Some of them support clustering, some don't. It would be good to make it abstract in the end to be able to plugin multiple search engines (so we don't have to worry too much about complex mappings). We should decide on just one. It would be good to find an alternative for Zebra, implement it and when Zebra shuts down we remove it. We don't want to use MariaDB- / MySQL-specific things because then we could switch DBs at some point, for instance moving to PostGreSQL. So it might not be feasible to use "only Database" as a search engine for small libraries (that is, convert the query into a DB search.) Mark's Normalization Plugin would be necessary for instance for database searching fields. A suggestion here would be for him to port it to core Koha. Then for small libraries, they can just use MariaDB database search; and for anyone experienced enough Elasticsearch. Zebra worked with ICU or other scripts pretty well. The problem there could be getting MariaDB to work with those if we want to go database-only. MariaDB apparently has stemming, stopwords, fuzzy etc. The query types we need to support are: - z39.50 - zebra (allows for SRU queries with CQL) - CCL / CQL If we want a drop-in replacement for zebra, it needs to have a way to query it, either z39.50/SRU or CCL/CQL. Other notes. Switching to searchable array makes your database bigger. It says it may make your relevancy worse, but Nick has never noticed any difference. "small" meaning below 100.000 records. So our recommendation could be "if you have below 50.000 records, you should use the Database search.. etc." **What to do:** The plan is to make sure the "3rd search engine option" = database, works well (so to write a search layer using the normalization plugin). And when that works well, we can get rid of zebra. Would need a workaround for making facets, but we needed that for zebra anyway. So the next step is to find out how to build a query with normalized data. Mark volunteered with Fred to try that this week and talk about it again end of the week. Mark bets it will be faster than Zebra/Elasticsearch (not that it matters because Koha displaying search results is the bottleneck, not the search engine). We also need to make sure there is a way for us to cleanly turn off Zebra when we are using Elasticsearch, because currently Koha is unhappy and warns a lot in logs when turning off Zebra even when ES is on. cait made a list for Zebra things that still annoy when Zebra is turned off. She will put a link to it in the hackfest channel. Nick notes in some instances, Aspen needs the zebra queue to know what to index from Koha. cait notes we need to fix DBD::MySQL to DBD::MariaDB at some point. (Database driver) Laurence discovered we are using many outdated perl libraries. We should probably update them, MariaDB/MySQL is a part of that. If at the end of the week it's not possible, we'll look at other possibilities, maybe other search engines. People also spoke (unrelated) about patron search with Elasticsearch. There are mixed opinions, it seems it might be quite overkill for the amount of patrons. Also could be problematic because of duplicating patron data, might not necessarily be a security problem but it would still not be gaining much. **Update Thursday:** Mark showed a POC of the search using only the database. For it to work, he needed to write a plugin called koha-nm2db-keyword-search: https://github.com/HKS3/koha-nm2db-keyword-search The plugin adds a MariaDB Fulltext index to query the value of subfields. It requires normalize marc2db: https://github.com/HKS3/koha-normalize-marc2db The query shows which tags the searched word was found in. It only uses the fields defined in the ES index. (so searches the same fields) You can use wildcards and other features of MariaDB. These are not the same as ES search syntax. The search is implemented as an API route, which would make it easily integrated into external websites! It would also allow for stemming. He is limiting to 200 results. He thinks about a week of work would be necessary for it to be usable enough to the Zebra search. You would have to build CQL and other placeholder support on top of it. Mark is trying to use the ES weights for relevancy instead of the MariaDB weights. Natural language searches in MariaDB have been there for a while, so it shouldn't be a problem for older installations. **How will we proceed?** See Bug 42164. KIT volunteers to test. Mark will test with 500.000 and with one million records. But he thinks it won't get much slower. Authorities could be a problem due to e.g. see from indexing needing to search and index the previous authority records in the biblio record. It could be problematic with non-latin characters, because MariaDB can't use ICU. Umlaute seem not to be a problem. We have to add cleaning for sql injection. Mark can't do it alone. Joubu points out we ideally need some code in common in the abstraction layer no matter what search engine; as it is, if we drop zebra, we still have an abstraction layer based on zebra. Mark thinks we should get the third search engine as a beta option in so we can have a quick option and the rest still works normally. Or we can keep it in the plugin as long as we like and then add it later on when all the features we need are there. It was decided the best way would be to keep the legacy abstraction layer and add a new one for the new search and make it better and pluggable. Maybe even start with two new ones so we know it works with different search engines. And define capabilities so we can say the engine can do this or that.