Fix plugin enabled config options

[joshdover]

Summary

Fixes #58713

This PR does two things:

• Adds the enabled key to any plugin config schemas that are missing it and must have it
• Fixes the configPath for any NP plugins that either didn't match their existing legacy configPrefix or the previous prefix they had prior to migration.
  • Note, there are some xpack plugins that do not have the xpack prefix. This is to maintain BWC with their previously defined settings such as translations and console_extensions. In a future change, these could be renamed using the deprecations framework, however in this PR I just wanted to get things in a BWC state.

Checklist

Delete any items that are not applicable to this PR.

• 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
• This was checked for keyboard-only and screenreader accessibility
• This renders correctly on smaller devices using a responsive layout. (You can test this in your browser
• This was checked for cross-browser compatibility, including a check against IE11

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[mikecote]

Alerting code LGTM

[mshustov]

should we add a warning or even throw an error if schema presents, but schema.enabled is not defined?

[pgayvallet]

should we add a warning or even throw an error if schema presents, but schema.enabled is not defined?

Maybe a warning. But if we want that to be mandatory, I think we should just add it when missing instead of throwing an error?

[weltenwort]

observability changes seem trivial 👍

[joshdover]

should we add a warning or even throw an error if schema presents, but schema.enabled is not defined?

Maybe a warning. But if we want that to be mandatory, I think we should just add it when missing instead of throwing an error?

I don't think an exception is the right idea. There are some plugins that I didn't add the enabled key to:

• licensing
• usage_collection
• kibana_legacy
• home

I choose not to add these for two main reasons:

• There are plugins that have these listed as a required dependency (when maybe they shouldn't, especially home); and/or
• Config keys for disabling these plugins did not currently exist AND there wasn't a good reason to add one right now

Since I'm just trying to get this in to 7.7 to maintain BWC in our config, I don't think we need to add these now. I would accept that maybe we should require the ability to disable of all of these plugins, but that will require more changes than I'm comfortable with for this PR.

I can do that in a follow up though!

[lukeelmers]

app arch changes LGTM

[timroes]

Kibana App code looks good to me.

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 7965794

History

• 💚 Build #35924 succeeded 604a3bb
• 💚 Build #35635 succeeded 6fcbd00

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream