Gaps in EVAM View Config Condition Selection Logic for new AI Search result template generation logic - Known Error

Gaps in EVAM View Config Condition Selection Logic for new AI Search result template generation logic Description With the new EVAM-lite implementation, there are 3 gaps in the logic for determining which View Config to use for a given search result: 1.) If a view config has a condition based on a field that isn't included in the list of table fields, that field won't be returned from AIS, and so the condition will never match. 2.) Even if the field is included on the Table Fields list, if it's a field that only exists on a child table of the table the indexed source is based on, the field won't be returned from AIS and so the condition will never match 3.) If the first view config for a particular table comes after the default/global view config, it will never be used. Whereas, EVAM had a more nuanced selection process that would look for all view configs that matched on the table before falling back to those for ancestor tables or the global/default table.

Steps to Reproduce

**Example 1:**

1.) Set the system property glide.search.evam.logger.enabled to true 2.) Open Service Portal and search for "new hire" 3.) Open the syslog, filter on created, and notice there is a message that contains: "[SEARCH EVAM] SearchResultTemplateGenerator: Using View Config 633c3b5d53a71010968addeeff7b1218 for Result with table sc_cat_item and sys_id 6690750f4f7b4200086eeed18110c761"

Observed: The incorrect view config is being used. 633c3b5d53a71010968addeeff7b1218 is the sys_id of the View Config called "Catalog Search Results", which is the generic view config for cat items, and does not have any conditions beyond table. But the "New Hire" cat item is an Order Guide, and there's an EVAM View Config specifically for that.

Expected: Service Portal's EVAM Def'n has a View Config called "Catalog Search Results - Order Guides", which has a condition of "sys_class_name=sc_cat_item_guide^EQ". This is the View Config that should be used, and the syslog entry should contain: "[SEARCH EVAM] SearchResultTemplateGenerator: Using View Config 44c37371c3202010825039b06e40dd4b for Result with table sc_cat_item and sys_id 6690750f4f7b4200086eeed18110c761"

(Note: I tweaked the logging a little to add the result type of regular or genius - so it will now read like "Using View Config 44c37371c3202010825039b06e40dd4b for REGULAR Result with table sc_cat_item and sys_id 6690750f4f7b4200086eeed18110c761")

** Example 2:** 1.) While still in SP, search for "change password". 2.) Again check the sys_log for which View Config was used. The sys_id of the Change Password record is 3c72dc91eb00210045e1a5115206fec7. It's a sc_cat_item_content record with content_type = external, so it should use the View Config with ID f5e3b371c3202010825039b06e40dd3b. However, before, it was using the default catalog one (633c3b5d53a71010968addeeff7b1218). And when you click on it, it should open the URL (outside of the portal).

** Example 3:** 0. Install the Content Publishing plugin 1. GoTo Content Publishing>Content Library> Create New 2. select News Article/Rich Content from modal window and click on next 3. Enter mandatory parameters on the design tab and publish the article 4. Goto /esc and search with the article title or headline text from the above news article 5. click on the news article/rich content from result

Actual: Opens in form view Expected: Opens in rich content page (though this is temporarily broken and is being handled by another team - so right now it redirects to the portal home page. But the key for this DEF is just to make sure the right view config is being used) In the syslog, the either "4d51db72ff742110277ba36cf43bf119" should be the view config ID if you created News, or "857a8e74ff252110277ba36cf43bf17a" if you created rich content

Workaround The issues mentioned here were only introduced in XP6 and YP0, and have already been fixed in XP7 and YP1. If a workaround is needed before upgrading to those patch versions, you can create and set the `glide.search.evam.use_legacy_template_generation` system property to true, which will cause the previously existing EVAM APIs to be used. This property can then be reverted after upgrading to XP7+ / YP1+ and it's confirmed that the issue no longer exists.