https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42156 --- Comment #19 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 197873 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197873&action=edit Bug 42156: (QA follow-up) Register the new 'authid' search field on upgrade Adding an entry to admin/searchengine/elasticsearch/mappings.yaml is only picked up by fresh installs or when an administrator explicitly resets the search mappings (rebuild_elasticsearch.pl -r). Existing installations would otherwise never see the new 'authid' index in the admin UI nor have it available as a matching index until they ran the reset. This atomicupdate inserts: - a search_field row for 'authid' (type 'stdno', staff_client + opac on) - search_marc_map rows for authorities/marc21/001 and authorities/unimarc/001 (INSERT IGNORE - the rows are shared with 'local-number' and usually already exist) - search_marc_to_field rows linking those MARC maps to the new field with sort on, matching mappings.yaml It is a no-op if 'authid' is already present. Administrators still need to rebuild the Elasticsearch index for the new field to become queryable - this is noted with say_info at the end. Test plan: 1 - On an existing instance without the patch: note there is no 'authid' field under Administration > Search engine configuration (Elasticsearch) for authorities. 2 - Apply the whole patchset. 3 - perl installer/data/mysql/updatedatabase.pl 4 - Re-check the search engine configuration: 'authid' appears for the authorities index, mapped to 001 for both MARC flavours. 5 - Run the update again - confirm the "already exists, skipping" warning. 6 - misc/search_tools/rebuild_elasticsearch.pl -r -v -a 7 - Confirm a matching rule using index 'authid' now works. Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.