search

elastic / kibana

Your window into the Elastic Stack
https://www.elastic.co/products/kibana
Other
19.62k stars 8.22k forks source link

Per-user profiles, settings in Kibana #17888

Open elasticmachine opened 7 years ago

elasticmachine commented 7 years ago

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:

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

elasticmachine commented 7 years ago

Original comment by @skearns64:

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

elasticmachine commented 7 years ago

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 commented 7 years ago

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 commented 6 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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:

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

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

"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 commented 5 years ago

@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.

cjcenizal commented 5 years ago

For reference, here are a few Console issues which will benefit from this service:

timroes commented 5 years ago

A couple of references for Kibana App related issues, that would require per-user settings:

kobelb commented 4 years ago

/cc @dontcallmesherryli @madirey this is the closest issue that we have that would allow you to persist user specific information.

elasticmachine commented 4 years ago

Pinging @elastic/kibana-core-ui (Team:Core UI)

elasticmachine commented 4 years ago

Pinging @elastic/kibana-platform (Team:Platform)

pgayvallet commented 4 years ago

Reopening the discussion, as https://github.com/elastic/kibana/issues/39259 would finally allow us to progress on this feature.

Not sure where to start, as there is a lot of unanswered questions in this issue, and lot of important ones that were not even asked yet. But here's my draft proposal:

Lexicon:

Per user settings versus per user profiles

The needs of having per-user persisted data are various and diverse, and it seems this issue has gathered quite a lot of them. I think it's important, before continuing the discussion, to make the distinction between these two things: per-user profile and per-user settings.

Note that if we follow this definition, per-user default space would be a PUP and not a PUS, as there is no equivalent / existent uiSetting. That means that if we plan on displaying the user 'settings' somewhere in the UI, we would need to add PUP support in addition to PUS to the page.

User data persistence system

If these two features are going to have distinct APIs, they could probably share the same user-data persistence mechanism. PUP would probably only need to be a thin server layer on top of it, while PUS would use it to enhance the existing uiSettings service.

We would be using SO as the data access layer. This is the most common solution, and we need SOs for OLS anyway, so there isn't really any questioning here I believe.

We saw previously that for both kind of user data, we will have per space and space-agnostic storage needs. The direct consequence is that we gonna need two distinct types of SO (as namespaceType is per type, not per object). We could name them global_user_data and space_user_data (at least that's the names I will be using here).

Underlying implementation

Ideally, that would be a new core service (userData ? userProfile ?). I would expect something really close to the current uiSettings API.

const userDataService = coreSetup.userData;

userDataService.register({
  id: 'defaultSpace',
  scope: 'global' // `global` | `namespace`,
  schema: schema.maybe(schema.string()),
  defaultValue: undefined,
  // not exhaustive 
})
const userDataClient = coreStart.userData.getScopedClient(request);
const defaultSpace = userDataClient.get<string | undefined>('defaultSpace');

Notes:

Now for the real question: if this is managed from within core, how do we retrieve the user's id/principal to be used to create the underlying saved objects or to access a user's object? This information is currently only accessible from the security plugin. We would need to expose an additional registration API to be able to register an 'identity provider' to core that would be able to retrieve a user principal from a request

User data entries registration

We could either allow consumers to insert any arbitrary data, or require them to declare all the existing PUD, in a similar way that what uiSettings does. From a design and architectural point of view, I think the second option is way better. It allows to add metadata to the PUD, such as type, validation, description, which is a significant pro, and I don't really see any cons. In that case, the userData API would be very similar to theuiSetting ones.

Initialisation

Each time a consumer will call the userData APIs, we will retrieve the required user's objects (global_user_data and space_user_data). In the case where the get calls returns a 404, we would initialize (create) the objects implicitly.

Per-user profile

Technically, per user profile is just a thin wrapper around this userData service. I'm not even sure we would really need to add an abstraction level here. Maybe the userData service should be directly accessed for user-profile manipulation?

Per-user settings

As already explained, per user settings are more complicated to design, as they will be interacting with the existing uiSettings service / functionality.

So now, how do we have user settings interact with uiSettings. Well, one option would be to say that the current uiSettings service/client remains unchanged, and that consumers that needs to access user-overridden settings would have to use a new service that we would be introducing. However, as realistically all current consumers of uiSettings will want to access the user overridden values if they exists, I think this is not the correct solution and that we will want to adapt uiSettings instead (this is a critical point, please tell me if you think I'm wrong here).

First question that comes to mind: How do we describe which uiSetting should be overridable by PUS? One option would be to change the UiSettingsParams type to allow specifying if a setting can be overridden by users. It could be something like allowUserOverride?: boolean // defaults to false.

Getting a value

uiSettingsClient.get currently behave that way:

We would now need to have that kind of workflow:

Note that in some rare cases (I'm mostly thinking about the advancedSettings management section), we would need to be able to only retrieve the customized/default value, as we need to still have a way to get the customized value of a setting instead of the user one to display in in advancedSettings. We would probably need to adapt get, getAll and others to add a new ignoreUserOverride: boolean option.

Setting a value

If I think that get should user user-overridden settings by default, I'm not 100% sure about set. But for consistency, I guess that's what we want to do. So by default uiSettings.set(name, value) would set the user-overridden setting value if the uiSettings allows user overrides.

As noted in previous section, we would need to be able to specifically set the customized value instead of the user one. For that case, we would either adapt the set APIs of the uiClient, or introduce a new setCustomized (name is horrible, but you get the idea) API to do that.

Regarding OLS usage for the userData service

Currently, the decision is to use OLS (that is going to be provided by security, which is a licensed plugin) to restrict access to a given user's global_user_data and space_user_data object (We would just use the SOC find api with these types to retrieve, for each type, the only instance that is owned by the user). The consequences of this decision are:

A possible solution would be to not use OLS to 'retrieve' the user setting objects. instead of using find assuming that the only returned object would be the one owned by the current user, we could just be using a deterministic id for a given user's globalUserSettings and spaceUserSettings (based on the user ID/principal) and access it with a plain get. That way:

Note: If we go with that, we also do not need to wait until OLSv1 is ready to start implementing this feature.

I think this would be a very reasonable option tbh, WDYT @legrego @kobelb

UI

Have anyone already though about how these user settings should be available to edit from the UI. I don't think it should be done from the advancedSettings management tab, but from a new user settings page. Not sure if this should be accessible via management, or via a new app that would be accessible from the top nav's user menu.

Why not advanced settings? It would be a mess to have a proper UI for administrator, as we would have to manage reading and writing both the customized settings and the user's. Also, functionally, I don't think it make much sense to have them at the same place. per-user settings are related to user-profile, so it should, imho, be acessible via the user menu.

Licensing

Have we though about which distribution we want to allow user settings for? Will this be a licensed feature, or will this be available in OSS? Note that if this is a licensed feature, it would not be possible to provide the feature from core, and we would need a xpack plugin instead. Note that in that case, we will have no choice but to leak licensed features into the core uiSettings API / internal implementation, which ideally would be avoided at all cost.

cc @kobelb @alexfrancoeur

LeeDr commented 4 years ago

When security is disabled, you would be able to access all users settings, however the settings used would still be the current user's, so the functionality is preserved, only its security is disabled (which feels just right)

When security is disabled you don't really have users, do you? I was thinking that without security enabled you just use local storage in the browser? Or am I missing something?

pgayvallet commented 4 years ago

When security is disabled you don't really have users, do you?

Well, from a pure vanilla OSS versus xpack, that's just right. I still have that crazy dream to have a better API design with core handling the responsibility/api of authz/authc and security being only a provider of the implementation. That's widely out of the scope of this issue though.

EDIT: But I guess that in our case, it doesn't change much, so the feature should probably be just disabled if security is not present.

I was thinking that without security enabled you just use local storage in the browser? Or am I missing something?

Workarounds such as client-side persisted data is not an option here imho.

Overall, that would just provide an incomplete implementation and introduce heavy divergences between when security is enabled and when it's not.

If API consumers wants to introduce fallback to localStorage when the feature is disabled, they would be free to do so (well, for user profile, not user uisettings overrides). But I don't see that like a serious implementation, or even fallback, to the userData service, for the reasons enumerated here.

legrego commented 4 years ago

@pgayvallet thanks for reviving this discussion, and for your well thought out proposal!

per-user profile, PUP are just persisted user data, i.e: Save order in Discover load list (#28498) Starred dashboards (#39038) or many others.

This is a nit, but I wouldn't consider Discover's save order to be part of my user profile. If I knew nothing about Kibana's internals, then I'd think of this as a preference or setting.

ideally, It would not be possible to have a user setting that is registered in both scopes. The reason being that in that case, a simple get(settingName) and set(settingName) would not be sufficient, as we would have to handle the case were a consumer may want to retrieve (or set) the value for a specific scope, and the scopes priorities in any operation.

I expect that we'll encounter settings that want to migrate to/from global <--> space aware as time goes on. We don't need to support this immediately, but it's something we should keep in mind as we define these APIs and constraints.

We could either allow consumers to insert any arbitrary data, or require them to declare all the existing PUD, in a similar way that what uiSettings does. From a design and architectural point of view, I think the second option is way better. It allows to add metadata to the PUD, such as type, validation, description, which is a significant pro, and I don't really see any cons. In that case, the userData API would be very similar to theuiSetting ones.

++

How do we describe which uiSetting should be overridable by PUS? One option would be to change the UiSettingsParams type to allow specifying if a setting can be overridden by users. It could be something like allowUserOverride?: boolean // defaults to false.

There are potentially two "levels" to this: 1) The settings that we want users to be able to override 2) The settings that Kibana administrators want their users to be able to override

I think a flag on the UiSettingsParams type makes sense for the former, but we'll probably want to give administrators the ability to define the latter in some way. They can use uiSettings.overrides.<setting-id> within kibana.yml to prevent certain settings from being changed today, but that override is scoped to the entire instance. Giving admins the ability to lock down these settings in a per-space fashion would be pretty valuable IMO.

Have anyone already though about how these user settings should be available to edit from the UI. I don't think it should be done from the advancedSettings management tab, but from a new user settings page. Not sure if this should be accessible via management, or via a new app that would be accessible from the top nav's user menu.

We haven't done any mockups that I'm aware of, but I completely agree with your assessment: Adding this to the existing "user profile" page from the top-right user menu makes sense to me, as does not exposing this within Advanced Settings.

We will probably want to provide a way for users to see their PUP data as well -- if not for them, then for us when we need to triage SDHs in the future.

A possible solution would be to not use OLS to 'retrieve' the user setting objects. instead of using find assuming that the only returned object would be the one owned by the current user, we could just be using a deterministic id for a given user's globalUserSettings and spaceUserSettings (based on the user ID/principal) and access it with a plain get

I don't see any glaring issues with this approach, but I feel like OLS is the more correct solution. We've historically (and currently) faced issues when relying on fixed SO ids, so I'm hesitant to introduce another set of them.

if this is managed from within core, how do we retrieve the user's id/principal to be used to create the underlying saved objects or to access a user's object? This information is currently only accessible from the security plugin. We would need to expose an additional registration API to be able to register an 'identity provider' to core that would be able to retrieve a user principal from a request

I think the answer to this will come out of the answers to some of the other questions (licensing, UX, etc), but I don't think this'll be a particularly difficult problem for us to solve.

pgayvallet commented 4 years ago

This is a nit, but I wouldn't consider Discover's save order to be part of my user profile. If I knew nothing about Kibana's internals, then I'd think of this as a preference or setting.

Naming is essential for correct understanding here, and more than a NIT, so thanks for this one. I used 'user profile' when I started writing my comment, to distinguish them from user (ui) settings, but I agree that's not correct. I'm not even sure this should be named 'preferences'. For me, a preference is something that is actively set by the user. Starred dashboards are not, imho, a 'preference'. Maybe we should just name that 'user data'

The user 'profile' (feature YTBD...) would imho just be another service on top of userData.

I expect that we'll encounter settings that want to migrate to/from global <--> space aware as time goes on. We don't need to support this immediately, but it's something we should keep in mind as we define these APIs and constraints.

As long as these kind of migration can be described in a declarative way from the setting/data descriptor, it shouldn't be an issue. We can't really use SO migration for that, as it would be object-to-object property 'copy' or 'move', but doing that in the userData service during setup or beginning of start seems realistic.

I think a flag on the UiSettingsParams type makes sense for the former, but we'll probably want to give administrators the ability to define the latter in some way.

Just to be sure, The settings that Kibana administrators want their users to be able to override (2) would be a subset of The settings that we want users to be able to override (1), right?

We will probably want to provide a way for users to see their PUP data as well

++, we'll need an UI for that. It could be as single as a checkbox in the 'new' user profile app/page to list all the registered user data instead of just what is considered as profile. Or a totally different view.

don't see any glaring issues with this approach, but I feel like OLS is the more correct solution. We've historically (and currently) faced issues when relying on fixed SO ids, so I'm hesitant to introduce another set of them.

I get your point (and I wouldn't expect anything else given your team 😄 ), and I'm not opposed to that. What bothers me the most, technically, when using OLS and not deterministic IDs, is the fact that we will be retrieving the user's global_user_data and space_user_data using a find operation. That's doesn't feel right to me tbh. But it may only be a detail.

The second thing is that it strengthen the dependency of this feature against the security plugin, as security is not only used to secure access/permission to a given user's 'data', but is also necessary for the user-data fetching mechanism/implementation. I may be wrong, but that would be a code smell for me.

mshustov commented 4 years ago

the proposed design looks good :+1:

The second thing is that it strengthen the dependency of this feature against the security plugin, as security is not only used to secure access/permission to a given user's 'data', but is also necessary for the user-data fetching mechanism/implementation. I may be wrong, but that would be a code smell for me.

If it bothers us, we can reconsider the decision made at https://github.com/elastic/kibana/pull/55327 about the owner of the user-data fetching mechanism/implementation that would make Security plugin implementation more complex though.

IIRC from v8.0 Security plugin cannot be disabled in Kibana without disabling the one in Elasticsearch https://github.com/elastic/kibana/issues/54023

legrego commented 4 years ago

Just to be sure, The settings that Kibana administrators want their users to be able to override (2) would be a subset of The settings that we want users to be able to override (1), right?

Yes, sorry for not making that clear. The set of settings that end users can override will be the intersection of (1) and (2)

The second thing is that it strengthen the dependency of this feature against the security plugin, as security is not only used to secure access/permission to a given user's 'data', but is also necessary for the user-data fetching mechanism/implementation. I may be wrong, but that would be a code smell for me.

That's a fair point. thinking

If it bothers us, we can reconsider the decision made at #55327 about the owner of the user-data fetching mechanism/implementation that would make Security plugin implementation more complex though.

Sorry for being dense, can you elaborate on this, @restrry?

IIRC from v8.0 Security plugin cannot be disabled in Kibana without disabling the one in Elasticsearch #54023

That's right, we want to prevent the security plugin from being disabled. This won't prevent security features from being disabled though (which I think you're alluding to anyway)

kobelb commented 4 years ago

There's a whole lot that I like about the proposed design. 🥰

I think that having a dedicated "user settings" page makes a lot of sense from the UX perspective, and it also allows us to not alter the privileges model for the Advanced Settings UI. Do you think we should denote in the Advanced Settings UI when a setting is no longer in effect because the user has customized this setting? I could see this being potentially confusing to users if they're changing a setting in Advanced Settings, and not seeing it take effect.

Is my understanding correct that we'd require the PUS and the PUP to both be registered using the following:

userDataService.register({
  id: 'defaultSpace',
  scope: 'global' // `global` | `namespace`,
  schema: schema.maybe(schema.string()),
  defaultValue: undefined,
  // not exhaustive 
})

How would we differentiate between a PUS user-data registry item and a PUP user-data registry item? Building on the following, do you envision the userData service being used for other purposes besides the PUP and the PUS?

Using a deterministic ID is an interesting idea. Any chance you can elaborate on how you see this working? I'm also interested in how we see this working with the caveats that @arisonl uncovered while exploring the user entity; particularly how the same person can authenticate with different realms and how two different people could authenticate with the same realm.

And one more question about our favorite topic, saved-object management's import/export. Do you see a path for us to allow PUS and PUP to be exported/imported? Is there anything so sensitive that we shouldn't allow users with access to saved-object management from being able to either see or change?

alexfrancoeur commented 4 years ago

At a high level, I agree with a dedicated user settings page and the proposal. As we dive into UX and licensing, it feels like we're getting to the point where we probably need some more detailed product requirements. Does this group agree? @arisonl has put a great document together for how we're thinking about user entities in Kibana - primarily focusing on the high level MVP definition and problems we are addressing. Aris, would you mind sharing with @pgayvallet and @restrry if you haven't? We seem to have buy-in for the most part but it will be good to get the core teams input. It makes sense to continue iterating on implementation details, but I'm guessing having some solid product requirements and designs will help provide some clarity on expectations and fill in any gaps.

@ryankeairns a user entity / settings in Kibana are becoming more of a priority for multiple initiatives. We'll likely need to starting thinking through UI/UX soon.

arisonl commented 4 years ago

@alexfrancoeur Confirming the User entity document is shared with @pgayvallet and @restrry.

ryankeairns commented 3 years ago

@pgayvallet another fantastic explanation! Thank you for writing this out, it's extremely beneficial.

+1 to the notion of an enhanced profile page and to Brandon's point about adding indicators to the advanced settings page.

@alexfrancoeur roger that. I'll add it to our design roadmap and get somebody lined up. Detailed product requirements would definitely help moves things along more quickly. Thank you.

pgayvallet commented 3 years ago

@kobelb

How would we differentiate between a PUS user-data registry item and a PUP user-data registry item?

That's an excellent question. In current implementation we don't. I'm not sure we necessarily need though. The way I see it, it is a low-level service meant to be used by higher level ones:

We may want to add a new property when registering userData entries though. Would not cost must and allow to distinguish the end usage of the userData entry

userDataService.register({
  id: 'defaultSpace',
  // ...{} other properties already listed
  type: 'setting' | 'profile' | 'other?'
})

wdyt?

Using a deterministic ID is an interesting idea. Any chance you can elaborate on how you see this working?

My (probably naive) idea would be to just use

And then use these deterministic IDs when searching for a user's object in a specific request context.

Do you see any problem with that, or would this KISS implementation work?

EDIT: first problem I see if the service is exposed from core: We don't know, atm, the space bound to the incoming request, as this is only a spaces concept. This problem goes away if the service is exposed from an xpack plugin I think? That may be an argument against having this service provided by core?

I'm also interested in how we see this working with the caveats that @arisonl uncovered while exploring the user entity; particularly how the same person can authenticate with different realms and how two different people could authenticate with the same realm

From the doc, the questions that would impact use here would probably be 

A native Kibana user may have the same username with a user logging in with an external realm username. We need a way to resolve such conflicts.
In the case of external realm-only users, a username needs to be resolved. An external username can be a number of things, depending on the realm setup. For example, it may be an email

From my understanding, For OLS we will have to find a way to have a unique identifier for each individual users. This seems like a complicated issue, but once this is addressed, we would just be using this unique identifier here. So to be honest, I would say that this is out of the scope of this issue, but wdyt? Did I miss anything?

And one more question about our favorite topic, saved-object management's import/export. Do you see a path for us to allow PUS and PUP to be exported/imported? Is there anything so sensitive that we shouldn't allow users with access to saved-object management from being able to either see or change?

Did not think one bit about that one tbh.

I see two use cases here:

If we want that, as users don't have access to SO management, I guess we would need to add an additional export/import workflow from the user profile page? Should we only allow to export profile, or all user-data? I'm not sure.

Depends on the answer to Is there anything so sensitive that we shouldn't allow users with access to saved-object management from being able to either see or change. If we decide it is acceptable for administrator to see a user's data. We would just add our internal SO types to the list of exportable types. Else, we would just not.

@alexfrancoeur

As we dive into UX and licensing, it feels like we're getting to the point where we probably need some more detailed product requirements. Does this group agree?

Can't agree more on that.

legrego commented 3 years ago

As we dive into UX and licensing, it feels like we're getting to the point where we probably need some more detailed product requirements. Does this group agree?

++ this would be great.

From my understanding, For OLS we will have to find a way to have a unique identifier for each individual users. This seems like a complicated issue

Yep. I was discussing this with the es-security team, and we're somewhat hesitant on relying on realm names as part the unique user identifier. At a very high level, we proposed a new set of ES APIs to store and retrieve user profile information (not necessarily the same as your PUP definition above). This would absolve Kibana from having to generate a unique user identifier, and instead allow ES to manage these. I have to do a more formal writeup of what this would look like, and having product requirements would go a long way here.

^ This proposal does couple the feature to the Stack's security features, so if that's not palatable from a product perspective, then we'll need to do some more brainstorming.

kobelb commented 3 years ago

My primary concern with segmenting the SUP and the SUS userData items, is that they both will be sharing the same "addressable space" when it comes to IDs. For example, if we just use the user-setting's ID for the id of the userData item, if we happen to have a SUP with the same ID, there will be a collision. This is most likely not a problem if we only have the SUP and SUS consuming userData, but if we add a bunch more consumers, it's potentially an issue then.

With regard to the deterministic IDs, I could see it working, but I think a lot of it depends on the ideal UX and product requirements. I can envision a few UI designs that might require us to structure the saved-objects in a manner that is not conducive to a saved-object for global settings, and a saved-object per space.

pgayvallet commented 3 years ago

My primary concern with segmenting the SUP and the SUS userData items, is that they both will be sharing the same "addressable space" when it comes to IDs. For example, if we just use the user-setting's ID for the id of the userData item, if we happen to have a SUP with the same ID, there will be a collision. This is most likely not a problem if we only have the SUP and SUS consuming userData, but if we add a bunch more consumers, it's potentially an issue then.

You meant PUP and PUS right :troll: ?

You're right regarding conflict risks. Adding a prefix for the key used to store the item in the SO document sounds reasonable. If could be done directly inside the userData, depending on the type, or it could be done from the higher-level services. Like, registering a defaultSpace PUP could, under the hood, register a profileDefaultSpace item to userData. The first one is probably better though, as it would remains an implementation detail of the lower-level service.

With regard to the deterministic IDs, I could see it working, but I think a lot of it depends on the ideal UX and product requirements. I can envision a few UI designs that might require us to structure the saved-objects in a manner that is not conducive to a saved-object for global settings, and a saved-object per space.

++. I think the next step is to wait for a more defined product requirement, and then do a second iteration on the technical proposal from there.

gimmic commented 3 years ago

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.

Bumping this a bit.. I didn't see this referenced again anywhere locally and stumbled across this issue from another search.

Personal user preferences should definitely include theme- I currently work in a shared space where the preference is 'dark' but would personally prefer the light theme. It is slightly insulting that it is a global setting, and not a per-user one.

TinaHeiligers commented 3 years ago

@pgayvallet Is the following high-level summary of where the discussion's at right now correct?:

There's a lot more detail in the comments above (and in my various summaries of them 😉 ) but the main question here is are we ready to move forward with an RFC or are there still too many open questions?

cc @joshdover @lukeelmers

mshustov commented 3 years ago

or a deterministic ID for user-level items

@TinaHeiligers a side-note: It still requires a user-specific id which might be added as a part of the OLS effort https://github.com/elastic/kibana/issues/82725

TinaHeiligers commented 3 years ago

I'll add it to our design roadmap and get somebody lined up. Detailed product requirements would definitely help moves things along more quickly. Thank you.

@ryankeairns Do you have any updates about timing yet?

ryankeairns commented 3 years ago

I'll add it to our design roadmap and get somebody lined up. Detailed product requirements would definitely help moves things along more quickly. Thank you.

@ryankeairns Do you have any updates about timing yet?

@TinaHeiligers We went through a quick requirements exercise with the Kibana Security team and have begun working on design mockups that will demonstrate updates to several areas of the UI including: the user profile screen, advanced settings, inline preferences, etc. @MichaelMarcialis will be presenting the initial design to the Kibana Security team next week. Would you like to be included?

TinaHeiligers commented 3 years ago

@ryankeairns Yes, please include me in that meeting. We've got a planning breakout session to start discussing the scope of the work. Could you also please share any notes and comments from gathering those requirements? Those will help with our discussions.

pgayvallet commented 3 years ago

@TinaHeiligers https://github.com/elastic/kibana/issues/17888#issuecomment-777825420

Is the following high-level summary of where the discussion's at right now correct?:

Sorry, I missed the ping before my PTOs. We already discussed it during the breakout session, but yea, those statements were correct.

EricPSU commented 2 years ago

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 commented 2 years ago

@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 commented 8 months ago

@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 commented 8 months ago

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:

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 commented 8 months ago

@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:

elasticmachine commented 6 months ago

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

IanLee1521 commented 6 months ago

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 commented 1 month ago

@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 commented 3 weeks ago

@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