-
Notifications
You must be signed in to change notification settings - Fork 918
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
Updates to Advanced Settings for theme Next
#4330
Comments
Should we also expose the compressed header as a toggle here? I only ask because we seem to be offering the sidenav as an option |
A couple questions/comments:
|
|
Im good with the incremental move, thanks for clarifying that |
Are advanced settings accessible to all users or just to the admins? If it's just admins, should the appearance settings live in a different place accessible to individual users, maybe stored in saved objects? |
@wbeckler -- today advanced settings are accessible to all users, although not all users have permission to update them. Additionally, if multitenancy is enabled, advanced settings only apply to your currently selected tenant. This is because advanced settings is a saved object, which co-exists in the .kibana index along with all other saved objects. We have identified a need for disambiguating between application (opensearch dashboards) settings, tenant (and down the road, project) settings, and finally user settings. My understanding is that today the OSD security plugin only provides role-based controls in OSD, and, there is no concept of a user, or a user object therefore, some settings are saved to local storage or are session based (such as recent pages, your last selected tenant, etc), but until we have a user object to save configuration options to, we are unable to move those items forward. Some appearance settings should be user (instead of tenant or application). For example, today, if I change the theme, or change dark/light mode, those settings apply to every user in the current tenant, or to every user in dashboards. |
Given that, shouldn't light/dark mode exist somewhere other than advanced settings, which always apply tenant-wide or dashboard-wide? |
It should in the long term, but that has dependencies. I think this issue is incremental to the current experience, so it just organizes some of the appearace settings that already exist into a category where they are grouped together. |
@wbeckler yes, this is a risk that was called out at the beginning of the theme change project (although we could have done a better job at github record keeping). We are in agreement that there needs to be a better end-user mechanism for manipulating light/dark mode selection (though there is a case to be made against end users choosing themes, especially in cases of custom branding). Perhaps instead of "one or the other" type solution, we provide the controls in two places - my initial thought was to add it as a quick-control to the user menu in the application top bar. We will still need to address permissions / security plugin issues with this. Two additional points:
|
Next
@joshuarrrr I have updated this issue with the north star design and alternate possibilities for the short term |
@joshuarrrr @wbeckler can I get confirmation on whether 'automatic' switch is in scope for 2.10? This would help with documentation and messaging and I can also firm up the details in the short term proposal included in the issue. |
Yes, I can confirm. |
No, automatic switching is not in scope for 2.10. |
@joshuarrrr will split off the remaining work that is targetted for 2.11. Completed all work related to 2.10. |
Wrapping this up for now, based on what we delivered for the 2.10 release:
Not completed:
I'll close this issue for now, as other improvements down the line will likely warrant revised designs, and we can reopen if needed.
There's not really a "General" category per se; any setting that doesn't specify a category will show up there, so we can definitely assign categories to existing settings at any point. |
In support of new options to control the look & feel of OpenSearch Dashboards, I would like to introduce a new controls within Advanced Settings. The north star "ideal" change for Advacned Settings would include introducing the "Appearance" category. At a later time, we will start to reorganize other settings and disambiguate "General" as it currently contains an unmanageable/unscannable and somewhat disorganized set of controls that could be grouped into smaller, more consumable settings types.
North star proposal
Appearance is added to the category list (the expression of which depends on the status of this issue) after General, and replace "Accessibility" - as there is currently only 1 accessibility setting which also is related to "Appearance".
These settings would contain the following as cherry-picked from General and Accessibility - as well as new options, marked:
OuiRadioCard
- (replacesOuiSwitch
in current Dark Mode). As per Switch default theme to "Next" from "V7" #4677 - for upgrading users, the radio button should reflect the previously selected mode.- Light Mode
- Dark Mode
- Automatic - this control utilizes browser settings to switch theme modes. The theme mode change will take place on page change (as in: if the browser setting dictates that at 5pm, the users browser experience switches into dark mode, do not prompt the user to refresh the page to switch into dark mode.)
- At a later time this change should apply without relying on page change.
Design:
Alternate options
OuiRadioCard
group with Light, Dark and Automatic optionsThe text was updated successfully, but these errors were encountered: