-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hides unknown uiSettings from the advanced settings page #128030
Hides unknown uiSettings from the advanced settings page #128030
Conversation
@@ -198,6 +198,7 @@ export class AdvancedSettings extends Component<AdvancedSettingsProps, AdvancedS | |||
}); | |||
}) | |||
.filter((c) => !c.readOnly) | |||
.filter((c) => !c.isCustom) // hide any settings that aren't explicitly registered by enabled plugins. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already have a flag that we can use to filter out any settings that aren't explicitly registered during Kibana setup and start lifecycles and don't need to necessarily add another one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
self review
@@ -268,6 +268,33 @@ describe('AdvancedSettings', () => { | |||
).toHaveLength(1); | |||
}); | |||
|
|||
it('should should not render a custom setting', async () => { | |||
// For various complicated reasons the mock returns false for isConfig, override that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pgayvallet the whole advanced_settings.test.ts
needs some serious rework. The test suite hasn't seen much "love" for a while and hacks around implementation within the AdvancedSettings
component.
I thought of refactoring this test but we will need to do that later as part of the Kibana profile initiative and chose to leave it as is right now to get this bug fix in.
@elasticmachine merge upstream |
Pinging @elastic/kibana-core (Team:Core) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I believe reusing the isCustom
property makes sense
@elasticmachine merge upstream |
💚 Build SucceededMetrics [docs]Async chunks
History
To update your PR or re-run it, just comment with: |
Resolves #94876
Settings that aren't registered by plugins are visible and editable in Stack Management > Kibana > Advanced Settings > General. We need to hide these from the UI without removing them from the underlying saved object. Hiding
custom
settings will also hide any settings registered by a plugin that's been disabled (e.g Reporting).Rather than introduce another flag, we reuse the isCustom property.
In this PR,
isCustom
flag to decide on when to show a setting or not.AdvancedSettings
page.This PR doesn't modify the underlying
uiSettings
saved object directly, because that should be done using an explicit migration.How to test this:
config
saved object)Should return a document similar to:
The following plugins can still be disabled:
Checklist
For maintainers