On embedded dashboards, show filter bar without "add filter" button OR control the fields that "add filter" allows.

[emarsc]

Is your feature request related to a problem? Please describe. I have a user that only has access to certain fields, but they are able to see the restricted fields when using the "add filter" button on embedded dashboards.

Of course, I can disable the filter bar, but then when the user interacts with the dashboard (clicking a keyword, time range, etc.), they are unable to see the filters that they have applied.

Describe the solution you'd like There are three possible solutions that would resolve this issue for me (in order of preference):

1.) Allow option to show filter bar without the "add filter" button for embedded dashboards - this would be the best solution for me right now.

2.) Allow some way to control of the fields that the user can see when adding a filter in dashboard configuration - or specifically do not show fields that the user does not have read access to.

3.) Give option to disable filtering on dashboards. This would block the user from adding filters when interacting with the visualizations.

Additional context

I am trying to set up embedded dashboards for read-only non-technical users that only have access to certain fields in certain indices. I am using opensearch internal user management for permissions. Regarding the second solution above, my expectation would be that the user shouldn't be able to see restricted fields when adding a filter, but they can and it seems that they will get 0 results without explanation (if anyone has any tips regarding the internal user management permissions that may remedy this, please let me know).

[seanneumann]

@davidlago does this fit for security plugin?

[davidlago]

@emarsc I'm assuming you are utilizing the FLS (field-level security) permissions in the backend, correct? If so yeah, these I don't think get considered when populating UI field selectors, so even though the underlying query would not work if the user can't see the fields, it is still a confusing experience to see fields that are not "queriable".

@opensearch-project/transfer-request could we please get this moved to the dashboards-security-plugin repo?

[emarsc]

@emarsc I'm assuming you are utilizing the FLS (field-level security) permissions in the backend, correct? If so yeah, these I don't think get considered when populating UI field selectors, so even though the underlying query would not work if the user can't see the fields, it is still a confusing experience to see fields that are not "queriable".

@opensearch-project/transfer-request could we please get this moved to the dashboards-security-plugin repo?

@davidlago

Yes. I am using the field level permissions. Agreed that it is a confusing experience for the user.

[cwperks]

[Triage] @cwperks Please update with findings from a deep dive.

[cwperks]

I traced through the call stack to try to understand how OpenSearch dashboards resolved from an index pattern to a list of fields to try to understand where it may be appropriate to apply a fix for this issue. indexPattern.fields is ultimately what gets displayed in the filter dropdown (see https://github.com/opensearch-project/OpenSearch-Dashboards/blob/main/src/plugins/data/public/ui/filter_bar/filter_editor/index.tsx#L275) so at some point in the resolution of fields the fields excluded by FLS need to be removed.

The trace starts in index_pattern.ts here: https://github.com/opensearch-project/OpenSearch-Dashboards/blob/fba380b149e491d62b3e5eec708f53d8dd83fed1/src/plugins/data/common/index_patterns/fields/field_list.ts#L57

The fields come from the saved object index pattern or from a refresh here: https://github.com/opensearch-project/OpenSearch-Dashboards/blob/main/src/plugins/data/common/index_patterns/index_patterns/index_patterns.ts#L394-L416

Refresh details can be found here: https://github.com/opensearch-project/OpenSearch-Dashboards/blob/main/src/plugins/data/common/index_patterns/index_patterns/index_patterns.ts#L266

This calls getFieldsForWildcard: https://github.com/opensearch-project/OpenSearch-Dashboards/blob/main/src/plugins/data/common/index_patterns/index_patterns/index_patterns.ts#L252

Which calls the _fields_for_wildcard API: https://github.com/opensearch-project/OpenSearch-Dashboards/blob/main/src/plugins/data/server/index_patterns/routes.ts

Which under the hood uses an IndexPatternFetcher: https://github.com/opensearch-project/OpenSearch-Dashboards/blob/main/src/plugins/data/server/index_patterns/fetcher/index_patterns_fetcher.ts#L66

And this calls the field capabilities API under the hood: https://github.com/opensearch-project/OpenSearch/blob/main/server/src/main/java/org/opensearch/rest/action/RestFieldCapabilitiesAction.java

When I create an index pattern as a user with FLS, it correctly does not include the fields that FLS excludes. When I create a dashboard from the index pattern and try to add a filter, I do not see the excluded fields in the filter dropdown. I believe that this issue arises when a dashboard is created from an index pattern that was created by a user with greater permissions than the user with FLS restrictions. Since the resolution from index pattern -> fields is done by getting the saved object via the saved object client, the fields are stored as part of the saved object.

Setting the isFieldRefreshRequired variable to always be true fixes the issue here: https://github.com/opensearch-project/OpenSearch-Dashboards/blob/main/src/plugins/data/common/index_patterns/index_patterns/index_patterns.ts#L413

[stephen-crawford]

Reached out to some Dashboards core maintainers because this change will require modifying the code base over there. I would like to be able to minimally determine whether the Security Dashboards is installed in order to force the refresh variable to true. Ideally, we would only check for the active user having DLS/FLS active, but even determining whether the Security Dashboards is installed is challenging since there is not an obvious method of checking the installed plugins.

[stephen-crawford]

@ananzh this was the issue we spoke about just so it adds to your GitHub notifications. :)

From offline conversation:

The core OpenSearch Dashboards code is designed to be independent of plugins, which makes it tricky to directly check for a plugin's presence or its settings from within core files like index_patterns.ts. Instead of modifying the core code, is there a way that you could extend the IndexPatternsService or some other parts from within the security dashboards plugin, which could override or wrap the isFieldRefreshRequired method to include the DLS/FLS check?