[uiSettings] Support deprecations API

[TinaHeiligers]

Today, we support the ability to mark a uiSetting as deprecated, which will surface a tooltip in the UI, however, we don't provide access to the deprecations API so that usages of these deprecated settings can be provided as part of the upgrade assistant.

We should look into a way to provide access to the deprecations API from uiSettings so that devs can give users more visibility into usage of deprecated settings.

Ideally we look into this at the same time as #123257 in case we can provide one solution to address both issues

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[lukeelmers]

I have no answers, just more questions 🙂

They mostly boil down to: what does it look like to deprecate a uiSetting?

Are we talking about:

• Marking a setting as deprecated in the UI with some explanation?
• Scanning SOs for the presence of deprecated settings so we can integrate with the deprecations service and surface them in upgrade assistant?
• Adding a mechanism to register migrations for settings that have been deprecated, so they can be removed from the SOs? (Currently there isn't a way to do this without adding a migration directly to core)
• Some combination of the above?

If teams are wanting to deprecate items for removal in 8.0, this is something we'll probably need to figure out soon.

[TinaHeiligers]

I think we'll end up with a combination of those. In fact, we actually have items that will need to be addressed first anyway.

For example:

• Settings owners should be the only ones who can deprecate it and should be the only ones using it. We'll need Plugins should only be able to directly access UiSettings that they registered #101907 first.
• there's already an item for "explore the need to uiSettings migrations", just not an issue for it yet. Maybe we don't need to support that right away but it might come up more.

• Marking a setting as deprecated in the UI with some explanation?

We could surface the deprecation warnings in a similar manner as the upgrade assistant, but initially maybe adding docs with those would be enough?

• Scanning SOs for the presence of deprecated settings so we can integrate with the deprecations service and surface them in upgrade assistant?

Those would be great to have but maybe more of an enhancement later?

I think we'll need to split #48925 up into phases and start addressing dependencies to get through all the work.

[timroes]

Thanks for the issue. A couple of notes:

Marking a setting as deprecated in the UI with some explanation?

This is already possible and exists. You can mark any advanced setting in the UI as Deprecated with a tooltip, and link.

Our need would especially be a deprecation node in the server log when starting up Kibana, IF the setting is still used (i.e. not the default value) in any existing space, so we can raise awareness for administrators that a deprecated setting is still used, who might not go to every spaces advanced setting page regularily.

[Bamieh]

@timroes can we rely solely on the UA for this rather than using server logs to admins?

1. Users would see deprecated ui settings relevant to their access level and only the ones changed.
2. We expect our users on cloud to use the UA for upgrades (and all users for that matter right?).
3. It would solve our issue with having to query all spaces to grab non default settings

[timroes]

@Bamieh From my latest understanding the Upgrade Assistant is only working for major version upgrades? Thus not use-ful for our need here, where we're deprecating and removing advanced settings within a couple of minors. If the UA is useful also for minor upgrades we def (also?) want to link into this.

[Bamieh]

@timroes That is true UA is in read-only mode during minor upgrades so it is not useful for us here.

[mshustov]

IF the setting is still used (i.e. not the default value) in any existing space, so we can raise awareness for administrators that a deprecated setting is still used, who might not go to every spaces advanced setting page regularily.

Do we really need to bother admins every time IF the setting is still used ?

I can see several different cases:

• a setting is removed. Kibana can ignore the setting or remove it on its own. No additional actions are required.
• a setting is not registered because a plugin-owner is disabled. Kibana might ignore the setting. Let's don't clutter up the console with un-actionable messages.
• setting parameters have been changed. Kibana should do its best to convert the saved setting value without user intervention. We might need to notify the user only if the setting cannot be changed in a compatible manner.

[timroes]

We actually DO change that setting technically without any problems. The point is, that we're removing settings that might have an effect on how that Kibana behaves (in this case where we need it, because we remove the legacy chart implementations, that they are still using). So in terms of make-it-minor and making breaking changes and removing stuff like that in a minor version, we feel it's best that we at least announce usage of those deprecated flags in the console before we're removing them altogether and from one minor to another the behavior e.g. of charts might just change (i.e. they might look different).

cc @timductive @stratoula (as the ones driving the removal of our old chart implementations)

[elasticmachine]

Pinging @elastic/appex-sharedux (Team:SharedUX)