Filter Saved Search Based on AppName Supported by Language

[LDrago27]

Description

This PR aims to filter out unsupported Saved Searches (SQL and PPL based Saved Queries are not supported for Visualization) across the application namely in Dashboards and Visualize.

Issues Resolved

Screenshot

Saved Search in Discover (contains all SQL, PPL, DQL, Lucene Searches)

Saved Search in Dashboards (contains DQL, Lucene based searches)

Saved Search in Visualize (contains DQL, Lucene based searches)

Testing the changes

Changelog

• skip

Check List

• All tests pass
  • yarn test:jest
  • yarn test:jest_integration
• New functionality includes testing.
• New functionality has been documented.
• Update CHANGELOG.md
• Commits are signed per the DCO using --signoff

[github-actions]

❌ Empty Changelog Section

The Changelog section in your PR description is empty. Please add a valid changelog entry or entries. If you did add a changelog entry, check to make sure that it was not accidentally included inside the comment block in the Changelog section.

[codecov]

Codecov Report

Attention: Patch coverage is 57.14286% with 9 lines in your changes missing coverage. Please review.

Project coverage is 60.58%. Comparing base (95929a6) to head (1fdbf88).
Report is 39 commits behind head on main.

Files with missing lines	Patch %	Lines
...aved_objects/public/finder/saved_object_finder.tsx	61.11%	4 Missing and 3 partials ⚠️
src/plugins/dashboard/public/plugin.tsx	0.00%	1 Missing ⚠️
src/plugins/visualizations/public/plugin.ts	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7999      +/-   ##
==========================================
- Coverage   61.09%   60.58%   -0.51%     
==========================================
  Files        3691     3738      +47     
  Lines       87310    88687    +1377     
  Branches    13433    13789     +356     
==========================================
+ Hits        53342    53735     +393     
- Misses      30721    31665     +944     
- Partials     3247     3287      +40     

Flag	Coverage Δ
Linux_1	28.75% <9.52%> (-0.58%)	⬇️
Linux_2	56.27% <ø> (+0.02%)	⬆️
Linux_3	37.50% <9.52%> (-0.44%)	⬇️
Linux_4	29.61% <57.89%> (+0.02%)	⬆️
Windows_1	28.77% <9.52%> (-0.58%)	⬇️
Windows_2	56.22% <ø> (+0.02%)	⬆️
Windows_3	37.50% <9.52%> (-0.44%)	⬇️
Windows_4	29.61% <57.89%> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kavilla]

oh sorry about. not catching this earlier. im not sure if we want to update the interface like this as it might be a breaking change for any plugin using this.

i see the saved objects plugin gets started up with the services and with it is the data plugin. potentially the same with the services.application? that way we don't need to update the interface. since i can see it already touches a bunch of plugins within OSD. But no positive any plugins outside this repo (non-OpenSearch project and OpenSearch project)

https://github.com/opensearch-project/OpenSearch-Dashboards/blob/main/src/plugins/saved_objects/public/plugin.ts#L57

[LDrago27]

@kavilla I tried this approach, however I see the downstream applications are directly importing the component without using the pluginStart props. Hence I decided against it.

[sejli]

@kavilla If we want to do a quick fix for this breaking change, we could make the new parameters optional.

data?: DataPublicPluginStart,
application?: ApplicationStart

[LDrago27]

Thanks @sejli I have taken your idea and made the new parameters as optional. Therefore if you don't pass in these params they should work in a similar way as before.

To highlight the non breaking nature of changes I have reverted back the changes made to the test where we were using it without the new params to ensure it does n't break the functionality elsewhere.

[kavilla]

i wonder if it makes it a little bit more scalable/safer to just have this as a pass a function

like from the dashboards it could be

 SavedObjectFinder: getSavedObjectFinder(
          savedObjects,
          uiSettings,
          searchFilterFn: (obj) => {
              const sourceObject = JSON.parse(
              obj.attributes?.kibanaSavedObjectMeta?.searchSourceJSON ?? null);
              const languageId = sourceObject?.query?.language;
              services.data.languageService?.getLanguage(languageId)?.supportedAppNames?.includes(currentAppId) ?? true;
          }
      )

[kavilla]

i think i only worry ensuring we dont end up adding more required plugins since i know a good amount of community members hit the APIs directly and even though this is the public side the saved objects plugin has been historically didn't need to care about the application which made it reliably abstracted and enforced a pattern for developers.

do we forsee in issues with introducing these concepts of language service to the saved object finder?

[LDrago27]

The overall change seems safe and the default behavior without the additional parameters remains unchanged for SavedObjectFinder. The saved_object_finder.test.tsx tests all use the default version of SavedObjectFinder without the optional parameters and the behavior remains unchanged.

In the meanwhile I have created the issue #8122 , which we can use to create a more scalable version of the above when required.