Skip to content
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

Timelion yml setting overrides feature controls #35267

Closed
lukeelmers opened this issue Apr 17, 2019 · 4 comments
Closed

Timelion yml setting overrides feature controls #35267

lukeelmers opened this issue Apr 17, 2019 · 4 comments
Labels
discuss Feature:Security/Feature Controls Platform Security - Spaces & Role Mgmt feature controls Feature:Timelion Timelion app and visualization Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! Team:Visualizations Visualization editors, elastic-charts and infrastructure

Comments

@lukeelmers
Copy link
Member

When using timelion feature controls (#31652), the timelion.ui.enabled yml config (#30131) always overrides the feature control and "wins", and the yml config is disabled by default.

When working on #35266, I realized that if an admin adds a timelion feature control to a role, they might be surprised to find that the icon never appears in the nav, even after explicitly granting permission to a particular role. So the timelion feature control really only works as expected if timelion.ui.enabled: true

Not sure the best way to address this; should we just not support timelion feature controls at all since we intend to deprecate the timelion app in favor of the timelion chart in visualize anyway?

Or should we conditionally show the timelion feature control based on the timelion.ui.enabled setting? Does it create weird state conflicts if a user has timelion.ui.enabled: true, saves a timelion feature control, but then decides to disable again and the feature control doesn't display in the role management UI, but is still saved to ES?

This relates somewhat to the discussion around hiding advanced settings when timelion is disabled (#30898). Should we also be hiding advanced settings for specific applications when those apps are disabled in feature controls? (Or maybe we are already doing this and I overlooked it?)

cc @kobelb @timroes @AlonaNadler

@lukeelmers lukeelmers added discuss Feature:Timelion Timelion app and visualization Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! Team:Visualizations Visualization editors, elastic-charts and infrastructure Feature:Security/Feature Controls Platform Security - Spaces & Role Mgmt feature controls labels Apr 17, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-security

@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-app

@kobelb
Copy link
Contributor

kobelb commented Apr 17, 2019

Or should we conditionally show the timelion feature control based on the timelion.ui.enabled setting? Does it create weird state conflicts if a user has timelion.ui.enabled: true, saves a timelion feature control, but then decides to disable again and the feature control doesn't display in the role management UI, but is still saved to ES?

This is my preference. It shouldn't have any negative effects to handle it this way, it's similar to the behavior that would exist if we had a plugin which provided a feature and then was subsequently uninstalled.

@kobelb
Copy link
Contributor

kobelb commented Nov 19, 2019

Resolved by #35266

@kobelb kobelb closed this as completed Nov 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss Feature:Security/Feature Controls Platform Security - Spaces & Role Mgmt feature controls Feature:Timelion Timelion app and visualization Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! Team:Visualizations Visualization editors, elastic-charts and infrastructure
Projects
None yet
Development

No branches or pull requests

3 participants