[Bug 43231] New: Bug 40658 breaks CLI for 25.11
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 Bug ID: 43231 Summary: Bug 40658 breaks CLI for 25.11 Initiative type: --- Sponsorship Sponsored status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: rel_25_11_candidate Severity: blocker Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs@lists.koha-community.org Reporter: martin.renvoize@openfifth.co.uk QA Contact: testopia@bugs.koha-community.org CC: aleisha@catalyst.net.nz, dghdghfghfgh04@gmail.com, lucas@bywatersolutions.com, mark@hofstetter.at, martin.renvoize@openfifth.co.uk, nick@bywatersolutions.com, pedro.amorim@openfifth.co.uk, tomascohen@gmail.com Depends on: 40658, 42795 Target Milestone: --- +++ This bug was initially created as a clone of Bug #42795 +++ This happened when trying to upgrade one of our Koha instances from Koha 25.11.04 to 25.11.05: Upgrade to 25.11.04.011 [18:49:23]: Bug 40658 - Ensure local-number is sortable ERROR: Exception 'Koha::Exception' thrown 'Unable to update mappings for index "koha_cust_biblios". Reason was: "mapper [local-number] cannot be changed from type [integer] to [text]". Index needs to be recreated and reindexed' So.. somehow the type is wrong in the index itself which makes me think we need to better catch that case and trigger a full re-index in a background task or something instead when that happens. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40658 [Bug 40658] When sorting by local-number we should use the sort field https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42795 [Bug 42795] Bug 40658 breaks CLI for 25.11 -- 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=43231 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Sponsorship status|Sponsored |Unsponsored -- 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=43231 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |martin.renvoize@openfifth.c |ity.org |o.uk -- 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=43231 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Trivial patch Status|ASSIGNED |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 --- Comment #1 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 203177 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203177&action=edit Bug 43231: Don't let a failed ES mapping update abort the DB upgrade The atomic update for bug 40658 (making local-number sortable) calls Koha::SearchEngine::Elasticsearch::Indexer->update_mappings() directly whenever Elasticsearch is enabled. If the existing index already has local-number mapped as a plain integer (as it did before local-number was made sortable), Elasticsearch refuses the in-place mapping change: mapper [local-number] cannot be changed from type [integer] to [text] update_mappings() catches that internally and marks the index status as needing a full recreate/reindex, but it then re-throws, so the exception was left to propagate out of the atomic update and abort the whole schema upgrade - even though Elasticsearch was enabled and otherwise working fine, and even though the failure is a known, already-handled case. Wrap the call in try/catch so a mapping failure only produces a warning in the upgrade output, and the schema upgrade continues. The "index needs to be recreated" status set by update_mappings() is already surfaced by admin/searchengine/elasticsearch/mappings.pl and acted on by misc/search_tools/rebuild_elasticsearch.pl, so no extra plumbing is needed to alert admins or fix the index afterwards. Test plan: 1. On an instance with Elasticsearch enabled and biblios indexed, force local-number's mapping to a non-sortable type, e.g.: PUT /koha_kohadev_biblios/_mapping { "properties": { "local-number": { "type": "integer" } } } 2. Roll the DB version back before 25.12.00.059 and re-run updatedatabase.pl (or koha-upgrade-schema) so it re-applies this revision. 3. Without this patch: the upgrade aborts with the Koha::Exception above and no later DB revisions are applied. 4. With this patch: the upgrade prints a warning and continues; later revisions still apply. admin/searchengine/elasticsearch/mappings.pl shows the biblios index as needing to be recreated. 5. Run misc/search_tools/rebuild_elasticsearch.pl -r -b to fix the index, confirm the warning clears. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |rel_26_05_candidate, | |rel_26_11_candidate -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 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=43231 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |26.11 Version|Main |25.11 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 --- Comment #2 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Setting Version to 25.11 as it's especially problematic at that point.. but it'll need applying to all branches 25.11 upwards -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david@davidnind.com --- Comment #3 from David Nind <david@davidnind.com> --- Happy to attempt a sign off, but I have no idea how to do steps 1 and 2. I tried the following, but this doesn't work to generate the error: 1. Start up KTD with Elasticsearch: ktd --search-engine es9 up 2. Access the KTD shell: ktd --shell 3. Check out Koha 25.11: - git checkout 25.11.x 4. Change Elasticsearch mapping for local-number: - Edit admin/searchengine/elasticsearch/mappings.yaml - Change the two entries for local-number (note: integer is not used as a type anywhere else in the file): . type: number to type: integer 5. Reset everything so the database structure is changed to 25.11.x: reset_all 6. Simulate an upgrade: - updatedatabase OR - sudo koha-upgrade-schema kohadev -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Bug 40658 breaks CLI for |Bug 40658 still breaks CLI |25.11 |for 25.11 after Bug 42795 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 --- Comment #4 from David Cook <dcook@prosentient.com.au> --- I've updated the bug title since it was a duplicate bug title with bug 42795... please correct if I'm wrong there... -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 --- Comment #5 from David Nind <david@davidnind.com> --- This has been sitting here a while. I'd like to test, but I need some specific instructions on how to do steps 1 and 2. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #6 from David Cook <dcook@prosentient.com.au> --- Please provide more comprehensive instructions for testers -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #203177|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=43231 --- Comment #7 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 208990 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=208990&action=edit Bug 43231: Don't let a failed ES mapping update abort the DB upgrade The atomic update for bug 40658 (making local-number sortable) calls Koha::SearchEngine::Elasticsearch::Indexer->update_mappings() directly whenever Elasticsearch is enabled. If the existing index already has local-number mapped as a plain integer (as it did before local-number was made sortable), Elasticsearch refuses the in-place mapping change: mapper [local-number] cannot be changed from type [integer] to [text] update_mappings() catches that internally and marks the index status as needing a full recreate/reindex, but it then re-throws, so the exception was left to propagate out of the atomic update and abort the whole schema upgrade - even though Elasticsearch was enabled and otherwise working fine, and even though the failure is a known, already-handled case. Wrap the call in try/catch so a mapping failure only produces a warning in the upgrade output, and the schema upgrade continues. The "index needs to be recreated" status set by update_mappings() is already surfaced by admin/searchengine/elasticsearch/mappings.pl and acted on by misc/search_tools/rebuild_elasticsearch.pl, so no extra plumbing is needed to alert admins or fix the index afterwards. To test: This needs Elasticsearch, and you have to fake an instance that was indexed before bug 40658: an index where local-number is an integer, while the database now maps local-number to text (Elasticsearch cannot change that in place). 1. Start KTD with Elasticsearch (any of es7/es8/es9 will do), e.g. ktd --search-engine es8 up -d then open a shell with ktd --shell and make sure the SearchEngine system preference is set to "Elasticsearch". 2. In the shell, build the index so that local-number is an integer: perl misc/search_tools/rebuild_elasticsearch.pl -d -r -b Check it with: curl -s "es:9200/koha_kohadev_biblios/_mapping?pretty" | grep -A3 '"local-number" : {' => the field has "type" : "integer" 3. Make the database look like it did before bug 40658 and map local-number to text. Run "ktd --dbshell" (outside the shell) and paste: UPDATE search_field SET type = '' WHERE name = 'local-number'; UPDATE search_marc_to_field SET sort = 0 WHERE search_field_id IN (SELECT id FROM search_field WHERE name = 'local-number'); UPDATE systempreferences SET value = '25.1200058' WHERE variable = 'Version'; (The Version preference is stored without dots: 25.12.00.058 is 25.1200058. Going back to just before 25.12.00.059 makes the upgrade run the Bug 40658 revision again.) 4. WITHOUT this patch: in the shell run perl installer/data/mysql/updatedatabase.pl => The upgrade stops at 25.12.00.059 with: ERROR: Exception 'Koha::Exception' thrown 'Unable to update mappings for index "koha_kohadev_biblios". Reason was: "mapper [local-number] cannot be changed from type [integer] to [text]". Index needs to be recreated and reindexed' Nothing after 25.12.00.059 is applied (the command exits with status 1 and the Version preference is still 25.1200058). 5. Apply this patch, repeat step 3 (the failed run changed the database), and run the upgrade again. => This time the 25.12.00.059 revision prints a warning instead: Unable to update Elasticsearch mappings for local-number (...). A full reindex is required, run misc/search_tools/rebuild_elasticsearch.pl -r -b and the upgrade carries on: 25.12.00.060 and all the later revisions are applied, and the Version preference ends up at the current version. 6. In the staff interface go to Administration > Catalog > Search engine configuration (Elasticsearch). => It says "Index 'koha_kohadev' needs to be recreated." 7. In the shell run perl misc/search_tools/rebuild_elasticsearch.pl -r -b and reload the page from step 6. => The warning is gone. 8. Sign off :-D Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff --- Comment #8 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Replying to the request for more comprehensive test instructions (comments 3, 5 and 6): I've rewritten the test plan in the commit message and re-attached the patch. The code is unchanged. I worked through the new steps from scratch on a KTD with Elasticsearch 8 to make sure they hold up: - On unpatched main, the upgrade stops at 25.12.00.059 with the reported 'mapper [local-number] cannot be changed from type [integer] to [text]' error, exits with status 1, and nothing after that revision is applied. - With the patch, the same state prints the warning and carries on: the later 50 or so revisions are applied and the Version ends up current. - The mappings page then shows "Index 'koha_kohadev' needs to be recreated.", and running misc/search_tools/rebuild_elasticsearch.pl -r -b makes the warning go away. Two things that were probably tripping people up in the old plan: - Step 1 said to PUT an integer mapping on the existing index, but Elasticsearch won't let you change it in place, and the problem is really a mismatch between the index (integer) and what update_mappings builds from the database (text). The new plan builds the index first and then changes the database's type for local-number, which reproduces the failure reliably. - The Version preference is stored without dots (25.12.00.058 is 25.1200058), so 'roll the DB version back' wasn't something you could just type. The new plan has the exact SQL to paste. David N, if you're still keen, the steps should now be copy and paste. Thanks both for pushing on this. Setting the status back to Needs Signoff. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #208990|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=43231 --- Comment #9 from David Nind <david@davidnind.com> --- Created attachment 210066 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=210066&action=edit Bug 43231: Don't let a failed ES mapping update abort the DB upgrade The atomic update for bug 40658 (making local-number sortable) calls Koha::SearchEngine::Elasticsearch::Indexer->update_mappings() directly whenever Elasticsearch is enabled. If the existing index already has local-number mapped as a plain integer (as it did before local-number was made sortable), Elasticsearch refuses the in-place mapping change: mapper [local-number] cannot be changed from type [integer] to [text] update_mappings() catches that internally and marks the index status as needing a full recreate/reindex, but it then re-throws, so the exception was left to propagate out of the atomic update and abort the whole schema upgrade - even though Elasticsearch was enabled and otherwise working fine, and even though the failure is a known, already-handled case. Wrap the call in try/catch so a mapping failure only produces a warning in the upgrade output, and the schema upgrade continues. The "index needs to be recreated" status set by update_mappings() is already surfaced by admin/searchengine/elasticsearch/mappings.pl and acted on by misc/search_tools/rebuild_elasticsearch.pl, so no extra plumbing is needed to alert admins or fix the index afterwards. To test: This needs Elasticsearch, and you have to fake an instance that was indexed before bug 40658: an index where local-number is an integer, while the database now maps local-number to text (Elasticsearch cannot change that in place). 1. Start KTD with Elasticsearch (any of es7/es8/es9 will do), e.g. ktd --search-engine es8 up -d then open a shell with ktd --shell and make sure the SearchEngine system preference is set to "Elasticsearch". 2. In the shell, build the index so that local-number is an integer: perl misc/search_tools/rebuild_elasticsearch.pl -d -r -b Check it with: curl -s "es:9200/koha_kohadev_biblios/_mapping?pretty" | grep -A3 '"local-number" : {' => the field has "type" : "integer" 3. Make the database look like it did before bug 40658 and map local-number to text. Run "ktd --dbshell" (outside the shell) and paste: UPDATE search_field SET type = '' WHERE name = 'local-number'; UPDATE search_marc_to_field SET sort = 0 WHERE search_field_id IN (SELECT id FROM search_field WHERE name = 'local-number'); UPDATE systempreferences SET value = '25.1200058' WHERE variable = 'Version'; (The Version preference is stored without dots: 25.12.00.058 is 25.1200058. Going back to just before 25.12.00.059 makes the upgrade run the Bug 40658 revision again.) 4. WITHOUT this patch: in the shell run perl installer/data/mysql/updatedatabase.pl => The upgrade stops at 25.12.00.059 with: ERROR: Exception 'Koha::Exception' thrown 'Unable to update mappings for index "koha_kohadev_biblios". Reason was: "mapper [local-number] cannot be changed from type [integer] to [text]". Index needs to be recreated and reindexed' Nothing after 25.12.00.059 is applied (the command exits with status 1 and the Version preference is still 25.1200058). 5. Apply this patch, repeat step 3 (the failed run changed the database), and run the upgrade again. => This time the 25.12.00.059 revision prints a warning instead: Unable to update Elasticsearch mappings for local-number (...). A full reindex is required, run misc/search_tools/rebuild_elasticsearch.pl -r -b and the upgrade carries on: 25.12.00.060 and all the later revisions are applied, and the Version preference ends up at the current version. 6. In the staff interface go to Administration > Catalog > Search engine configuration (Elasticsearch). => It says "Index 'koha_kohadev' needs to be recreated." 7. In the shell run perl misc/search_tools/rebuild_elasticsearch.pl -r -b and reload the page from step 6. => The warning is gone. 8. Sign off :-D Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 --- Comment #10 from David Nind <david@davidnind.com> --- Thanks Martin for the test plan! Now signed off. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |lisette@bywatersolutions.co |y.org |m -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA --- Comment #11 from Lisette Scheer <lisette@bywatersolutions.com> --- Thanks for the helpful test plan! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #210066|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=43231 --- Comment #12 from Lisette Scheer <lisette@bywatersolutions.com> --- Created attachment 210674 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=210674&action=edit Bug 43231: Don't let a failed ES mapping update abort the DB upgrade The atomic update for bug 40658 (making local-number sortable) calls Koha::SearchEngine::Elasticsearch::Indexer->update_mappings() directly whenever Elasticsearch is enabled. If the existing index already has local-number mapped as a plain integer (as it did before local-number was made sortable), Elasticsearch refuses the in-place mapping change: mapper [local-number] cannot be changed from type [integer] to [text] update_mappings() catches that internally and marks the index status as needing a full recreate/reindex, but it then re-throws, so the exception was left to propagate out of the atomic update and abort the whole schema upgrade - even though Elasticsearch was enabled and otherwise working fine, and even though the failure is a known, already-handled case. Wrap the call in try/catch so a mapping failure only produces a warning in the upgrade output, and the schema upgrade continues. The "index needs to be recreated" status set by update_mappings() is already surfaced by admin/searchengine/elasticsearch/mappings.pl and acted on by misc/search_tools/rebuild_elasticsearch.pl, so no extra plumbing is needed to alert admins or fix the index afterwards. To test: This needs Elasticsearch, and you have to fake an instance that was indexed before bug 40658: an index where local-number is an integer, while the database now maps local-number to text (Elasticsearch cannot change that in place). 1. Start KTD with Elasticsearch (any of es7/es8/es9 will do), e.g. ktd --search-engine es8 up -d then open a shell with ktd --shell and make sure the SearchEngine system preference is set to "Elasticsearch". 2. In the shell, build the index so that local-number is an integer: perl misc/search_tools/rebuild_elasticsearch.pl -d -r -b Check it with: curl -s "es:9200/koha_kohadev_biblios/_mapping?pretty" | grep -A3 '"local-number" : {' => the field has "type" : "integer" 3. Make the database look like it did before bug 40658 and map local-number to text. Run "ktd --dbshell" (outside the shell) and paste: UPDATE search_field SET type = '' WHERE name = 'local-number'; UPDATE search_marc_to_field SET sort = 0 WHERE search_field_id IN (SELECT id FROM search_field WHERE name = 'local-number'); UPDATE systempreferences SET value = '25.1200058' WHERE variable = 'Version'; (The Version preference is stored without dots: 25.12.00.058 is 25.1200058. Going back to just before 25.12.00.059 makes the upgrade run the Bug 40658 revision again.) 4. WITHOUT this patch: in the shell run perl installer/data/mysql/updatedatabase.pl => The upgrade stops at 25.12.00.059 with: ERROR: Exception 'Koha::Exception' thrown 'Unable to update mappings for index "koha_kohadev_biblios". Reason was: "mapper [local-number] cannot be changed from type [integer] to [text]". Index needs to be recreated and reindexed' Nothing after 25.12.00.059 is applied (the command exits with status 1 and the Version preference is still 25.1200058). 5. Apply this patch, repeat step 3 (the failed run changed the database), and run the upgrade again. => This time the 25.12.00.059 revision prints a warning instead: Unable to update Elasticsearch mappings for local-number (...). A full reindex is required, run misc/search_tools/rebuild_elasticsearch.pl -r -b and the upgrade carries on: 25.12.00.060 and all the later revisions are applied, and the Version preference ends up at the current version. 6. In the staff interface go to Administration > Catalog > Search engine configuration (Elasticsearch). => It says "Index 'koha_kohadev' needs to be recreated." 7. In the shell run perl misc/search_tools/rebuild_elasticsearch.pl -r -b and reload the page from step 6. => The warning is gone. 8. Sign off :-D Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to main Version(s)| |26.11.00 released in| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 --- Comment #13 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- Thanks everyone! Pushed to main for 26.11! -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org