Per-user profiles, settings in Kibana

[elasticmachine]

Original comment by @tbragin:

As it seems to relate to permissions, I decided to file this issue here, but I am not sure ultimately if this functionality belongs in core Kibana or in X-Pack (security).

The ask is to introduce ability to make some default settings in Kibana per-user, for instance:

• Default space
• Default index pattern
• Default starting page
• Timezone
• Date format
• Theme (light mode/dark mode)
• Start of week day
• Language, once we introduce internationalization (? - Splunk has it configurable per-user)
• Session timeout (? - Graylog has it configurable per-user)
• Private workspaces for draft visualizations and dashboards

cc: @epixa @uboness @skearns64 @jaymode @lukasolson

[elasticmachine]

Original comment by @skearns64:

Thanks for filing! I would suggest also adding "Visible Applications" as another per-user setting.

[elasticmachine]

Original comment by @LeeDr:

Copying this from my duplicate issue since I think its a significant usability problem in the current release.

With security enabled, if a user doesn't have access to the default index pattern they're going to see an ugly error message EVERY TIME THEY LOG IN! Plus they have to select the actual index pattern they do have access to every time they log in.

Discover: [index_not_found_exception] no such index, with { index_uuid=na index=%5Bfilebeat-*%5D }

!LINK REDACTED

[elasticmachine]

Original comment by @tbragin:

from @geekpete

Describe the feature:

This might tie in to the per-user settings issue: LINK REDACTED

The ability to set defaults for all users.
Specific example is setting defaults for the Advanced Settings (sig terms, certainty, max docs per field) and Drill-downs (url parameter type) in Graph.
So that when any user goes to create a new graph workspace the defaults will be in place and won't need to be adjusted each time by each user.

Some of these settings (advanced settings) get saved if you save a visualization, where as others do not (drill-downs).

It would be great to at least be able to set defaults for all users, but perhaps even set defaults per some other grouping (eg, role or other things).

Labelled with Graph due to my specific example, though the functionality need not be specific to graph.

[elasticmachine]

Original comment by @cjgeode:

+1 - this came up with a call with a customer on 20-Nov-2017. They were looking for something as basic as the ability for users to be able to set their own local timezone when viewing data instead of changing it globally.

[cjcenizal]

@elastic/kibana-security I have an idea for supporting this feature which seems pretty simple. Let's say we add a "Preferences" plugin (or add a preferences service to core).

This plugin exposes three methods, setPreference(key, value), getPreference(key, value), and registerPreferenceManager(key, setPreferenceCallback, getPreferenceCallback). The first two methods are pretty straightforward; all they do is allow you to set and get preferences. registerPreferenceManager can be used to register interceptor methods which replace the default methods.

Under the hood, this plugin will use local storage to persist settings, by default. The Security plugin can use registerPreferenceManager to intercept requests for setting and getting preferences, and use the logged-in user's information to set and get these preferences from a system index. We can even set it up so that Security can use the local storage preferences by default if the user hasn't specified anything for them. The plugin will just need to call the callbacks and pass these values as arguments.

Thoughts, anyone?

[kobelb]

@cjcenizal I definitely think we need a solution similar to the one that you're proposing. Were you thinking that this would be integrated within Kibana's "Advanced Settings" screens?

[cjcenizal]

@kobelb I think “Advanced Settings” could be a consumer of the preferences plugin/service. I’m not sure if it has any special requirements though.

[legrego]

I could see "Advanced Settings" taking advantage of this, but I could also see Kibana administrators wanting to restrict which settings are configurable at a user level. We'd want to think through how this interacts with space-aware advanced settings too. Should preferences themselves be space-aware?

I like the idea of adding a preferences service to core. That way it'll be a first-class concept that OSS plugins can easily take advantage of. Then security can associate preferences to users via saved objects, or similar.

[cjcenizal]

I could also see Kibana administrators wanting to restrict which settings are configurable at a user level.

This makes sense, but I think this concern is orthogonal to the preferences service, since the service is just a persistence mechanism. I think Advanced Settings would allow users with the admin role to assign access roles and default values to each setting, which would be persisted in the config document saved to the .kibana index. Advanced Settings would then enable/disable (or even show/hide) those settings depending on the logged-in user's roles. To determine which settings to apply, Advanced Settings could follow this logic:

1. If the user doesn't have access to the setting, use the default value specified by the admin.
2. Otherwise, retrieve the setting from the preferences service.
3. Under the hood, this will be provided by the Security/Spaces hook (I might be incorrectly conflating the two, but I assume they could collaborate to provide the correct setting for the user/space).

We'd want to think through how this interacts with space-aware advanced settings too. Should preferences themselves be space-aware?

I think in many or even most cases, an Advanced Setting would make the most sense as a global setting. But I do think it makes sense to give devs the option of defining a setting to be space-aware, Just In Case™.

Then security can associate preferences to users via saved objects, or similar.

Spot on!

[epixa]

The term "preference" sticks out in my mind, not as a concern necessarily but as something we should clarify. We do or want to store other things that are user-specific that do not seem to fall under the category of a "preference", and I had always figured we'd have a single solution to both of these things.

Some things we might call preferences:

• Advanced setting overrides
• Side nav expand/collapse default
• Default space

Some things that are user-specific but not really "preferences":

• Console history
• Recent or frequently accessed apps
• Previous nav state
• Acknowledged notifications

I can see resolving this discrepancy in one of two ways:

1. Use a different term than "preferences"
2. Have a separate user-data persistence service that backs our preference implementation but can also be accessed directly for powering other user-specific data

Thoughts?

[cjcenizal]

user-data persistence service that backs our preference implementation but can also be accessed directly for powering other user-specific data

@epixa This description is what I had in mind when I proposed the preferences service. I chose "preferences" for the name because I didn't want this to be confused with settings, but I'm open to any name, e.g. "user data". Personally I find "user data" to be too ambiguous, and am OK with thinking of "preferences" as "persisted user-specific data" but I don't feel strongly about this.

As a consumer, I don't think I would want separate services for the two lists you gave because then I have to think about which one my data should go into when all I really want to do is save it and load it later.

[cpmoore]

Ideally the UI theme would be included in personal settings too.

I’m slightly opposed to using local storage to store a user’s preferences. Local storage does not share across browsers. As a user I would expect my settings to persist regardless of where I was accessing kibana from.

[jinmu03]

"User specific experience" is a major feature planned on Stack Service and Global UI team's 7.x roadmap. We could use user profile(at Kibana top right corner) to let user specify their preference such as default homepage, index pattern, timezone, favorite Spaces, etc.

[cjcenizal]

@cpmoore I agree with you about local storage and your expectations! We should aim for a UX where your preferences are available when you log in, wherever you are. The local storage option is a fallback for when there is no mechanism for identifying the user (e.g. the OSS distribution when Security isn't installed). At least this way, if you're using the same computer, you won't lose your preferences when you end your session.

This does raise an interesting challenge though. What do we do with preferences stored in local storage when the user upgrades from OSS to use X-Pack and Security? We'll need to build in a mechanism for transparently migrating those preferences from local storage to ES.

[EricPSU]

I see this was at one time tentatively scheduled for the 7.14 release, but that obviously didn't happen. Is there a timeline for this issue or is it on any future roadmap? This ticket was opened in 2017 and there was a lot of activity at the end of 2020 so it looked promising, but now we've gone all of 2021 without any meaningful discussion :(

[legrego]

@EricPSU we are actively making progress on a number of prerequisites in this space, as this is one of my team's top priorities. I can't offer a timeline, but I can promise you this hasn't been forgotten.

[IanLee1521]

@EricPSU we are actively making progress on a number of prerequisites in this space, as this is one of my team's top priorities. I can't offer a timeline, but I can promise you this hasn't been forgotten.

@legrego -- Checking in from 2024 and just wondering if this is still something on the roadmap, and what all might be contributing to blocking this. Thanks for considering, this would definitely be useful for us too.

[legrego]

Hey @IanLee1521, thanks for checking in. We have made some progress here. Kibana & Elasticsearch have introduced the notion of User Profiles, which provides us with a persistent record for each user, and a mechanism for storing user-specific data such as preferences.

With this foundation in place, we've added support for:

• User avatars via Introduce user profiles #132522, which landed in v8.4.0.
• Per-user dark mode setting via Per User Dark Mode Preference #151507, which landed in v8.8.0.

As for what's next -- I'd love to hear your thoughts. Which settings specifically would you find helpful, and why? I can't make promises, but your input will help us prioritize.

[IanLee1521]

@legrego -- Awesome to hear! I can think of a few off the top of my head that would be great, but I'll also circle back if I think of others:

• Default route: Currently in advanced settings, but that hits everyone.. I have multiple different types of users that would love to have different landing pages when they log in. e.g. the discover page, vs a particular dashboard, but different dashboards per user / team (security vs infrastructure teams)
• Default space: Similar to the first one, we've built some per team functionality into different spaces, but teams have to navigate there on their own.
• Query language: Topay there is an advanced setting for Lucene vs KQL, it would be nice for a per-user that also included ESQL since that is becoming more prominent.
• "Short URL": This one actually isn't even a global setting yet, but when sharing links, it would be great to be able to default to short urls instead of the long ones (I never want those)
• "Defer loading panels below "the fold"": Currently an advanced setting, but might not want it to be globally true (probably would be a good "per dashboard" setting as well really).

[elasticmachine]

Pinging @elastic/appex-sharedux (Team:SharedUX)

[IanLee1521]

Another one I thought of that would be good to see is being able to user configure / override my personal default time window.

In an environment there might be some users that are mostly looking at 24 hours of data, and others that mostly look at 7 or 30 days of data at a time.

[petrklapka]

@clintandrewhall @kevinsweet - this has been open for a very long time. @legrego 's crew have made progress with User Profiles and we've built a few features on it, but still no UX for per user settings. The issue and comments contains over a dozen useful value adds. Consider for planning Q3? If not, what about the 6 or 12 month horizon?

[kevinsweet]

@clintandrewhall @kevinsweet - this has been open for a very long time. @legrego 's crew have made progress with User Profiles and we've built a few features on it, but still no UX for per user settings. The issue and comments contains over a dozen useful value adds. Consider for planning Q3? If not, what about the 6 or 12 month horizon?

thanks for raising - it's on my list for considering next Q