[Advanced Settings] Integrate new Settings application into stateful Kibana

[ElenaStoeva]

Closes #172922

Summary

This PR:

• Integrates the new Settings application (packages/kbn-management/settings/application) into stateful Kibana and removes the old management_app from the src/plugins/advanced_settings plugin.
• Adds support for section registry in the new Settings application, so that other plugins can add their own sections to the Advanced settings app.
• Adds functionality for disabling saving of settings based on the provided capabilities of the current user.

"Usage collection" section in Global settings:

How to test

Testing Advanced settings in stateful Kibana:

1. Start Es with yarn es snapshot and Kibana with yarn start
2. Go to Stack Management -> Advanced Settings
3. Verify that the app functions correctly. Both tabs (for space and global settings) should be displayed, setting fields should be editable and saveable, etc.

Testing the section registry
Currently, telemetry_management_section is the only plugin that registers a section - the "Usage collection" section under the "Global settings" tab. This should work correctly in stateful Kibana.

1. Start Es with yarn es snapshot --license=trial and Kibana with yarn start
2. Go to Stack Management -> Advanced Settings and select the "Global settings" tab
3. Scroll down and verify that the "Usage collection" section is displayed and works as expected.

Testing with different capabilities:

1. Start Es with yarn es snapshot and Kibana with yarn start
2. Go to Stack Management -> Roles
3. Create a role that has "Read" access to Advanced settings and one that doesn't have any access.
4. Create users with each of these two roles.
5. Log in with these users and verify that the user with "Read" access can see the app but cannot edit it, and the user with no privileges cannot access the app.

Testing Advanced settings in serverless Kibana:
The Advanced settings app in serverless shouldn't be affected by these changes.

1. Start Es with yarn es serverless and Kibana with yarn serverless-{es/oblt/security}
2. Go to Management -> Advanced Settings
3. Verify that the app functions correctly. There shouldn't be any tabs as there are no spaces.

[ElenaStoeva]

/ci

[ElenaStoeva]

/ci

[ElenaStoeva]

/ci

[ElenaStoeva]

/ci

[elasticmachine]

Pinging @elastic/platform-deployment-management (Team:Deployment Management)

[mattkime]

data discovery changes look good and work well

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 4302ca2
• Storybooks Preview
• Cloud Deployment

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
advancedSettings	62	107	+45
management	208	114	-94
total			-49

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
@kbn/management-settings-types	5	10	+5
advancedSettings	15	2	-13
total			-8

Any counts in public APIs

Total count of every any typed public API. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats any for more detailed information.

id	before	after	diff
advancedSettings	1	0	-1

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
advancedSettings	53.2KB	36.3KB	-16.8KB
management	77.8KB	43.2KB	-34.6KB
total			-51.4KB

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id	before	after	diff
advancedSettings	2	0	-2

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
advancedSettings	9.6KB	6.5KB	-3.2KB
management	13.3KB	10.7KB	-2.6KB
total			-5.8KB

Unknown metric groups

API count

id	before	after	diff
@kbn/management-settings-types	83	88	+5
advancedSettings	17	2	-15
total			-10

async chunk count

id	before	after	diff
advancedSettings	2	1	-1
management	2	1	-1
total			-2

ESLint disabled line counts

id	before	after	diff
advancedSettings	2	0	-2

References to deprecated APIs

id	before	after	diff
advancedSettings	8	0	-8

Total ESLint disabled count

id	before	after	diff
advancedSettings	2	0	-2

History

• 💔 Build #189723 failed 65d43bf
• 💔 Build #189693 failed 41cab4a
• 💔 Build #189689 failed 67168c5
• 💔 Build #189645 failed 9487b54
• 💔 Build #189017 failed 1e1085a

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

cc @ElenaStoeva

[pgayvallet]

🥳

[MichaelMarcialis]

Forgive a potentially silly question on my part, but why is it that the usage collection switch saves without the bottom bar appearing and asking the user whether they wish to save or cancel their changes? I only ask from a consistency standpoint, as it seems that every other option in advanced settings utilizes that bottom bar approach.

[rshen91]

Great changes, tested locally

[ElenaStoeva]

Forgive a potentially silly question on my part, but why is it that the usage collection switch saves without the bottom bar appearing and asking the user whether they wish to save or cancel their changes? I only ask from a consistency standpoint, as it seems that every other option in advanced settings utilizes that bottom bar approach.

Thanks for the review @MichaelMarcialis! The Advanced settings plugin has functionality that allows other plugins to add their own sections in the app and render their own components in these sections, with logic that is separate from the logic for the rest of the Advanced setting fields. The "Usage collection" section is an example - it is added by the telemetry_management_section plugin and its whole functionality logic is defined in that plugin. That's why toggling the "Usage collection" setting would not trigger the bottom bar as it happens for the other settings.

Please keep in mind that this is not something that is added by this PR - this behaviour has been like this for a while. The PR only replaces the old Advanced settings codebase with a recently developed and improved code. The UI is not really affected in any way.

Edit: There is actually one change in the UI but it is minor: before, the "Revert to default" link would be displayed once the setting changes are saved, and now it is displayed once any change is made in the setting fields.

[yuliacech]

Great work with the settings plugin, @ElenaStoeva!
I re-tested locally and it seems to be working correctly. I have 1 question about the access management: when a role has "read only" access to settings for all spaces, I was expecting to see both tabs in read only mode. But there is only 1 tab and the global settings are hidden, is this the intended UX?

[ElenaStoeva]

Great work with the settings plugin, @ElenaStoeva! I re-tested locally and it seems to be working correctly. I have 1 question about the access management: when a role has "read only" access to settings for all spaces, I was expecting to see both tabs in read only mode. But there is only 1 tab and the global settings are hidden, is this the intended UX?

Thanks for the review @yuliacech! Regarding your question, when you created the role, did you provide access to the Advanced settings feature only? If that's the case, the other Kibana features are disabled which seems to also disable the custom_branding plugin and so it doesn't register its global settings, which means there are no global settings. When there are no registered global settings, we don't render the Global settings tab (see line 83 in packages/kbn-management/settings/application/application.tsx in this PR). If you make the role have "read only" access to all Kibana features, the Global settings should be displayed.

[yuliacech]

Thanks a lot, @ElenaStoeva! The global settings are displayed for the read only role.

[MichaelMarcialis]

Please keep in mind that this is not something that is added by this PR - this behaviour has been like this for a while. The PR only replaces the old Advanced settings codebase with a recently developed and improved code. The UI is not really affected in any way.

Ah, thanks for that context, @ElenaStoeva! Will give it a review now.