Open neptunian opened 3 months ago
Pinging @elastic/appex-sharedux (Team:SharedUX)
Pinging @elastic/kibana-security (Team:Security)
@neptunian, thank you for brining this up. Could you please point us to some specific examples in code and UI where uiSettings are updated like this? Would like to explore
Sure! I believe all of these cases are using the hook, useEditableSettings. I'm changing it in https://github.com/elastic/kibana/pull/189920 to catch errors (like 403) so we can inform users.
Same as above, but improving with error messaging and checks in https://github.com/elastic/kibana/pull/189920
Currently, advanced settings in Kibana are controlled by a global permission. Users assigned to a custom role with “all” access to specific plugins (e.g., APM, Infra, AI Assistant Management, Profiling) cannot save settings registered through
uiSettings
within their respective apps without the “Advanced Settings” permission. It seems that plugin authors may not be aware of the dependency on the “Advanced Settings” permission, as there is no UX indicating the need for this permission and the failures aren't caught or properly handled. This creates a confusing UX where changes appear to be saved (sometimes even showing success messages) but are not actually applied, with no error feedback.A workaround is to give the user the Advanced Settings privilege. However, this is too broad for cases where the user should only have access to settings for a specific app.
Should plugin authors avoid using Advanced Settings if they want users with "all" access to their application to be able to modify settings? Or is it possible to add some granularity to advanced settings, where if a user has "all" access to a specific plugin, they also get access to Advanced Settings related to that plugin?