-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
Spaces - Hiding management link #38472
Conversation
Pinging @elastic/kibana-security |
catalogue: {}, | ||
} as Capabilities | ||
); | ||
merge({}, ...sources); |
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 were doing a "shallow merge" before, so the management section defined in the spaces plugin was clobbering the one in the kibana plugin.
@@ -18,7 +18,7 @@ import routes from 'ui/routes'; | |||
import { AdvancedSettingsSubtitle } from './components/advanced_settings_subtitle'; | |||
import { AdvancedSettingsTitle } from './components/advanced_settings_title'; | |||
|
|||
const MANAGE_SPACES_KEY = 'manage_spaces'; | |||
const MANAGE_SPACES_KEY = 'spaces'; |
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.
It felt weird to have the ui capability management.kibana.manage_spaces
so I changed this. It's now management.kibana.spaces
.
💔 Build Failed |
💔 Build Failed |
💚 Build Succeeded |
ACK: reviewing today/tomorrow |
|
||
return capabilities; | ||
}, | ||
merge( |
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're changing from a shallow merge to a deep merge to support the new management.kibana.spaces
flag. Originally, this was intentionally designed as a shallow merge so that plugins would not clobber capabilities which didn't belong to them. While it's true that merge
won't allow a plugin to delete capabilities defined by other plugins, the addition of capabilities to other plugin's "buckets" is likely not something we want to encourage/support.
I know we've discussed letting plugins enhance the capabilities of other plugins, but I don't know if this is the way we want to do so. Since management
is a defined key of the Capabilities
interface, how do you feel about allowing the merge for this key, but not for the rest?
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.
The previous implementation wasn't preventing duplicate definitions of the same first-level ui capability: https://codepen.io/kobelb/pen/MMWROw?editors=0012. We take advantage of this for building the catalogue
ui capabilities: some of them are hard-coded here and we add to this list within the xpack_main plugin here.
While it's true that merge won't allow a plugin to delete capabilities defined by other plugins, the addition of capabilities to other plugin's "buckets" is likely not something we want to encourage/support.
I agree, but I don't believe those restrictions where previously enforced, at least not when using injectDefaultVars
(when we first implemented FC) or the new uiCapabilities
. We have some enforcement on this within xpack_main
here, but this is only for merging the ui capabilities that we derive from the feature registration.
I can look at changing spaces to not use uiCapabilities
to define the management section, and instead augment uiCapabilitiesForFeatures, but we'll still need the ability to merge all of these "deeply".
Since management is a defined key of the Capabilities interface, how do you feel about allowing the merge for this key, but not for the rest?
I think the proper solution to this problem is to follow through on #36221 and make it so that each of these "ui capability sections" is able to define it's own rules and so we can enforce these restrictions throughout the system, I was trying to prevent making this a dependency for fixing this specific issue though.
I added tests with 4d21c34 to ensure we aren't clobbering anything, and added additional safeguards. Does this assuage any of your previous concerns?
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.
I can look at changing spaces to not use uiCapabilities to define the management section, and instead augment uiCapabilitiesForFeatures, but we'll still need the ability to merge all of these "deeply".
So... we can't do this at the moment because we don't register a "Spaces" feature, and these actions are hard-coded here: https://github.com/elastic/kibana/pull/38472/files#diff-f5ed4149300a16c9d74494d7b470b450R68. I don't know what I was thinking previously.
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.
I think the proper solution to this problem is to follow through on #36221 and make it so that each of these "ui capability sections" is able to define it's own rules and so we can enforce these restrictions throughout the system, I was trying to prevent making this a dependency for fixing this specific issue though.
Agreed, thanks for the thoughtful followup!
I added tests with 4d21c34 to ensure we aren't clobbering anything, and added additional safeguards. Does this assuage any of your previous concerns?
❤️
@@ -21,6 +21,7 @@ const reactRootNodeId = 'manageSpacesReactRoot'; | |||
routes.when('/management/spaces/list', { | |||
template, | |||
k7Breadcrumbs: getListBreadcrumbs, | |||
requireUICapability: 'spaces.manage', |
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.
The other management routes use their management.${section}.${feature}
UI Capability to control access. Do we want to follow suite here and use management.kibana.spaces
?
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.
Sure, I'll change this to be consistent.
💔 Build Failed |
💚 Build Succeeded |
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!
* Changing the Spaces management section to behave like the other FC controlled sections * Adding those glorious tests and fixing a bug * Fixing some test descriptions * Making the mergeCapabilities operation emulate the old behavior * Fixing privileges test with the addition of the new action * Updating jest snapshot * Adding tests, preventing additional clobbering * Changing requireUICapability to use management.kibana.spaces
💔 Build Failed |
Prior to this change, the Spaces management link was always being displayed, even if the user didn't have privileges. Now that we have uiCapabilities, we can hide this when appropriate!
"Release Note: Hiding the spaces management link when the user doesn't have privileges to manage spaces"