Dark mode cannot be set per user

[sshock]

Describe the bug

Dark Mode should be a user-configurable setting.

To Reproduce
Steps to reproduce the behavior:

1. Go into Stack Management => Advanced Settings
2. Turn dark mode on or off

Expected behavior
Dark mode is turned on/off only for users who wish to inherit the global default.

Actual behavior
Dark mode is turned on/off for everyone in the entire large company and users have no way to override it.

OpenSearch Version
1.3.2

Dashboards Version
1.3.2

[kavilla]

Hello @sshock!

Thanks opening!

I just wanted to make a quick note: users who wish to inherit the global default isn't accurate to the current state of things. Not blaming you though because I think the naming is confusing and a lot of users have had this complaint. Based on this doc, the global tenant is the tenant that is shared between users.

When you set the dark mode in the global tenant it gets stored in the system index .kibana and when a user switches to a global tenant they will get results from .kibana. When users switch to a private tenant, the security plugin creates a specific system index for that user, for example, .kibana_userxyz_1. At that point, that user's OpenSearch Dashboards will utilize their system index to load up visualizations, dashboards, filters, index-patterns, and settings. A private tenant does not have access to the global tenant's data and vice-versa. Often we see users state that they can't see any of their index-patterns but because they are on a private tenant but they created all that in the global tenant.

So I just wanted to clear that up because that is kind of what the problem is right now. Users who use the global tenant will access the same data (ie settings), users who use their private tenant have their own data (ie settings). Therefore it's not so much a bug as a feature request because the current implementation of the security plugin limits this. However, I do know that there are talks about re-inventing security (I believe this #1215). Where the implementation could be storing every user in the .kibana and append metadata that controls the permissions the doc. At which point, users will be using the same system index for data and therefore settings.

Let me know if you have any questions.

But since this is due to the current implementation of the security plugin I will re-route to the security plugin repo to see if they could provide any more insight.

Thank you!

[sshock]

Thanks @kavilla . I don't fully understand the security model, but just to summarize what I think you're saying: it's not so much a bug as a feature because a company can work around this problem by creating a separate private tenant for each user, and each user can set dark mode how they want in their private tenant. Is that right?

That doesn't seem very workable to me, because it also means every user has to copy the shared dashboards from the global tenant to their private tenant, and then, well, they aren't shared anymore.

These are very different:

• Dashboards and Visualizations: users do want the ability to share these and benefit from each other.
• Dark mode on/off: this is a setting that a user wants to choose for themselves and not force onto or inherit from anyone else.

[kgcreative]

@setiah, @davidlago, @kamingleung -- wanted to get this in your radars as we keep continuing to think about dashboards, security models, user permissions and admin experience.

[kavilla]

I don't fully understand the security model, but just to summarize what I think you're saying: it's not so much a bug as a feature because a company can work around this problem by creating a separate private tenant for each user, and each user can set dark mode how they want in their private tenant. Is that right?

Sorry about the confusion. I was kind of saying that there isn't a workaround because by design the security plugin doesn't support this. But I think i should support this so in the future there are plans to re-design security in a way that it can support this functionality.

[cwperks]

@kavilla This is not a feature security plugin is planning on supporting. For UX features, please transfer this back to the Dashboards repository.

This bug should be where the team invested in resolving this issue can support the work. If its necessary to make a code change in security repos then we would be happy to accept a PR.

[peternied]

@kavilla This is a good feature request, but the security team isn't focused on user experience changes of this nature. If there is a data store needed that handles per user configuration, it might make sense for that to be implemented as part of the security plugin dashboards codebase, but the features and functionality that are offered using that store should be part of Dashboards.

[kavilla]

@kavilla This is a good feature request, but the security team isn't focused on user experience changes of this nature. If there is a data store needed that handles per user configuration, it might make sense for that to be implemented as part of the security plugin dashboards codebase, but the features and functionality that are offered using that store should be part of Dashboards.

@peternied,

It's a little bit of a gray area. The concept of user and tenancy does not currently exist for OSD. The problem occurs how the security dashboards introduces tenants and how the data is stored with a per user configuration.

Due multitenancy creating multiple system indices, each index has it's own document with a type of config. This config document has the settings values for dark mode. From my understanding what @sshock is requesting that private tenants should be using the config document by a system admin for settings instead of each private tenant having their own document to pull configs from. Which is basically, not compatible with the current state of the security plugin and there's nothing we could do from our side from a UX perspective.

For UX features, please transfer this back to the Dashboards repository.
This bug should be where the team invested in resolving this issue can support the work.

@cwperks

This seems surprising to me and I was not made aware. We have multiple OpenSearch Dashboards external plugins that we do not maintain from a core perspective. Doesn't seem to make sense to me that if there is a bug in an external plugin that the bug should exist in the core repo and the core repo's maintainers are responsible for fixing it. We also do not have the proper expertise as a maintainer of the security dashboards team would have.

could you provide some clarity there? Is it due to specifically with the security plugin and the planned work to roll permissions in OpenSearch Dashboards?

[peternied]

@kavilla I think we've found a troublesome area in our breakdown of features within OpenSearch and Dashboards, I think we should have a discussion to iron out our expectations and how we want to resolve this issue - could you set something up?

[sshock]

Also, I think there may still be some confusion. @kavilla We're not even using private tenants at my company, and my goal is not at all for private tenants to be able to inherit settings from the Global tenant.

If anything it is quite the opposite of that. It is for users to be able to choose their own setting for dark mode, which I assume they already can within their own private tenant and that won't affect anyone else, but the problem is users can't set it within the Global tenant (or a custom tenant) without affecting everyone else.

While using the "Global" tenant there is only a single setting for Dark mode that all users in the entire company get forced on them with no way to override. One choice affects all the hundreds or thousands of employees and they all have to like it and live with it. Or even worse, if everyone is allowed to change settings in the global tenant, now you have an even crazier situation, which is all day long every day having it change back and forth between light and dark mode at the whim of each random user who goes in and changes it, affecting everyone else multiple times throughout the day.

I don't know how user settings work or if user settings are even an actual thing right now, though I imagine it must be a real thing because somewhere it keeps track of what my roles are and which tenant I am currently on. Wherever it keeps track of "what is my current tenant", maybe that is where it could also keep track of "do I want dark mode or not".

[peternied]

@sshock First off, thanks for bearing with us as we get our house in order. With our implementation, we are not planning on support this scenario.

However, for the initiatives of Dashboards - see issue #1405, Dashboards Anywhere will enable features like customized settings per user.

@kavilla How would you like to resolve this issue? - I think the next step is to close it, but you might have a way to map it into the future plans.

[kgcreative]

@peternied & @kavilla -- perhaps we tag this as a feature request instead of a bug? That will allow us to keep it open, and close it when we do implement the changes resolve this.

[sshock]

I'm definitely in favor of calling it a feature instead of a bug if that is needed to keep it open. I'll change the title but will need someone else to change the tag.

Any idea on the timeline of the Dashboards Anywhere initiative?

Finally, is there any way to work around this until then? For example, can I put a dark=true in the URL? Or can it be easily changed by an individual using a browser extension like Stylus?

Thanks!

[joshuarrrr]

I just wanted to highlight what I think is a key takeaway from @sshock:

I don't know how user settings work or if user settings are even an actual thing right now, though I imagine it must be a real thing because somewhere it keeps track of what my roles are and which tenant I am currently on. Wherever it keeps track of "what is my current tenant", maybe that is where it could also keep track of "do I want dark mode or not".

It seems that our current data model overloads the system index with a bunch of heterogeneous settings. Within the core dashboards repo, this approach, while not exactly clean, causes no problems because "user" is not really a core concept. But for plugins that do need to distinguish between different types of settings (such as the security plugin), I think it's reasonable to expect them to be better separated by usage, rather than use the system index for any data that needs persistence.

[cliu123]

@sshock Yes, with the current design,the Advanced Settings is tied with tenants. The logic behind the design is that tenant intends to provide consistent user experience for all users selecting a same tenant. But your request is actually valid, it would help if we can have flexibility for users to configure personal preferences that can be applied to all tenants globally. Thanks for bringing this up!

[ThiefMaster]

Can't you use the client's preference instead of making this a server-side change?

https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme

[kgcreative]

Can't you use the client's preference instead of making this a server-side change?

https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme

In the fullness of time, yes. We will add a "Dark | Light | Match System Preferences" -- however, our CSS stack is woefully out of date, and that's not something that the current theming system can support, so it requires some additional work to refactor OUI to accomodate for this

[flytrader]

Describe the bug

Dark Mode should be a user-configurable setting.

To Reproduce Steps to reproduce the behavior:

1. Go into Stack Management => Advanced Settings
2. Turn dark mode on or off

Expected behavior Dark mode is turned on/off only for users who wish to inherit the global default.

Actual behavior Dark mode is turned on/off for everyone in the entire large company and users have no way to override it.

OpenSearch Version 1.3.2

Dashboards Version 1.3.2

It can be modified per user. All the NonDefault values that are changed in a users Private Tenant/Advanced settings is visible with the GET command. You can also see if they did change something and reverted it to default (see last example).

curl -X GET -u "user:password" "opensearchendpoint/.kibana_/_search"

            "config": {
                    "buildNum": 301202401,
                    "defaultIndex": "indexnumber",
                    "theme:darkMode": true,
                    "dateFormat:dow": "Monday",
                    "history:limit": 666
                }

With Default values exept the theme:darkMode

             "config": {
                    "buildNum": 301202401,
                    "defaultIndex": "indexnumber",
                    "theme:darkMode": true,
                    "dateFormat:dow": null,
                    "history:limit": null
                }

[mthemis-provenir]

Has there been any progress on this since the discussions last year? We're facing a problem here whereby most people prefer dark mode, but for others it makes it hard to read due to how their eyes work. I'd consider this not a regular feature, but an accessibility feature.

It can be worked around by the users setting up their private tenant with the various index patterns, but it means configuration drift when we add / remove / update them in the global tenant.