Timelion yml setting overrides feature controls #35267
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
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 hastimelion.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
The text was updated successfully, but these errors were encountered: