Spaces - Hiding management link #38472
Conversation
kobelb
added
the
Team:Security
|
Pinging @elastic/kibana-security |
kobelb
added
enhancement
kobelb
changed the title
| catalogue: {}, | ||
| } as Capabilities | ||
| ); | ||
| merge({}, ...sources); |
There was a problem hiding this comment.
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.
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.
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.
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.
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.
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.
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.
Sure, I'll change this to be consistent.
💔 Build Failed |
💚 Build Succeeded |
* 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
kobelb
added
release_note:enhancement
and removed
enhancement
💔 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"