[Discover] Managed data view improvement

[christineweng]

Summary

This PR adds a managed property to DataView type. It leveraged the existing managed property in saved objects, when a data view is created, managed is also passed to SO creation.

Major changes:

• Kibana managed data views (from integrations, discover and security) now have a Managed tag. The tags are present consistently across applications
• When viewing an existing data view, user is able to duplicate the data view via the new Duplicate button
• When clicking Managed this data view for a managed data view, the form is disabled from editing. User has the option to click Duplicate, which will open a new flyout with the indices populated
• New fields cannot be saved in a managed data view
• In Stack management -> Data views, editing a managed data view also shows a disabled form. Managed tag is added.
• Out of the scope of this PR: Duplicate is not available in stack management -> data views -> edit. If the data view is managed, the form is disabled and save button is not present

Screen.Recording.2025-09-04.at.2.18.03.PM.mov

Data view editor flyout logic

As the variation of the editor form increase from 2 scenarios to 4, additional logic is added. A small refactoring was made to onDataViewCreated to standardized the props, so that it can be reused by the duplicate logic (when duplicating, it is essentially the same behavior as creating a data view.

UI updates

Checklist

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the docker list
• This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The release_note:breaking label should be applied in these situations.
• Flaky Test Runner was used on any tests changed
• The PR description includes the appropriate Release Notes section, and the correct release_note:* label is applied per the guidelines

[michaelolo24]

@davismcphee who would we need to update on the docs side about documenting this change in a release note? Not sure what the process is for platform here..

[davismcphee]

I don't think we should expose managed in the public API. Is it needed? I'm under the impression all internal requests run through the content management API that uses the saved object client under the hood.

[christineweng]

I'm not too familiar with internal/external API, is removing this line sufficient to keep it internal?

[michaelolo24]

Yep, should be. Sorry for the delayed response here!

[davismcphee]

I think it should be, and maybe removing from the schema in src/platform/plugins/shared/data_views/server/rest_api_routes/schema.ts too.

[michaelolo24]

Not really on you here, but should this be wrapped in a try catch? fyi @davismcphee

[davismcphee]

More of a question for the Presentation team as Unified Search owners, but it definitely could be. Even something like data.dataViews.getIdsWithTitle().catch(() => []) would stop things from blowing up, although I guess it must not fail much as is or we'd probably hear about it 😄

[davismcphee]

Great job! The code changes are looking good overall. I left some questions and feedback in addition to what @michaelolo24 already added, but it seems like we're on the right track. I have a few comments around the UX, but I'll save them for the One Discover sync so we can discuss.

A couple of things I noticed when testing locally:

A user is still able to implicitly modify a managed data view through the field editor flyout and persist the changes. I think for this case, we can probably just do a check for managed and completely disable the ability to save, with a tooltip along the lines of Fields cannot be edited on managed data views. Duplicate the data view in order to make changes.:

It looks like managed data views can still be edited from data view management. This might be related to the isEdit thing added in this PR. We may need to figure out a way to handle this without each data view editor consumer having to explicitly pass isEdit since it can be error prone if missed:

[davismcphee]

More of a question for the Presentation team as Unified Search owners, but it definitely could be. Even something like data.dataViews.getIdsWithTitle().catch(() => []) would stop things from blowing up, although I guess it must not fail much as is or we'd probably hear about it 😄

[davismcphee]

On a totally unrelated note since I just happened to notice it, @elastic/obs-ux-logs-team shouldn't this just be { id: ALL_LOGS_DATA_VIEW_ID } like it is here?

kibana/x-pack/solutions/observability/plugins/observability_logs_explorer/public/logs_explorer_url_schema.ts

Lines 54 to 56 in 1bc72b0

	return {
	id: ALL_LOGS_DATA_VIEW_ID,
	};

[gbamparop]

@thomheymann @weltenwort is this a leftover from #209565? Or we need this for redirects?

[thomheymann]

@davismcphee Yeh, looks like All Logs is used as a fallback which should be using the ALL_LOGS_DATA_VIEW_ID data view.

@gbamparop This code was introduced as part of #215867 to pass app state from Logs Stream component to Discover.

[weltenwort]

Agreed. Although I suspect this is a dead code path since the conditional earlier in that function already seems to cover all cases and we'd never reach that fall-through. For cleanliness's sake one could turn the 'all' branch into the default to remove this.