Admin Space

[kobelb]

I'm hoping we can come up with a new title for this after deciding what we're actually going to implement. However, I'm keeping the previous title for the time being to ensure we're solving the same problem we originally set out to accomplish.

Currently, when a user first logs into Kibana and they have access to more than one space, they're forced to select a space to continue:

This is limiting because in the future we'd like to add various functionality which operates across all spaces:

1. the ability to manage saved objects across all spaces
2. the ability to view all alerts across all spaces
3. the ability to view ML jobs across all spaces

We could potentially add this functionality within the management application, after addressing #37283, but it seems like we'd want to allow the user to "skip" the space selector and have access to all "cluster" and "global kibana" sections at least.

One added complication is that Spaces is currently a plugin, so we'd have to figure out how we'd like for this to behave in OSS when Spaces isn't a plugin and when the user is licensed to use Spaces but it isn't enabled.

Current mockups: https://marvelapp.com/52b8616/screen/57582729

[elasticmachine]

Pinging @elastic/kibana-security

[kobelb]

/cc @cchaos

[elasticmachine]

Pinging @elastic/kibana-design

[epixa]

I think we can accomplish most of our goals here without a fundamental change to spaces. Instead, we can provide space “templates” that admins can select when creating a new space that predefine feature controls for that space. One of those templates can be an admin template, which enables all of the stack management and monitoring features. We can then disable those in the alternative recommended template that we’s anticipate admins using for most spaces they create.

In the future, space templates could be created by admins themselves to make managing large multi-space installs easier.

Edit: This feature would also make a big impact on our too-many-apps UX issue since it will encourage folks to limit the apps to what is necessary.

[kobelb]

I think we can accomplish most of our goals here without a fundamental change to spaces. Instead, we can provide space “templates” that admins can select when creating a new space that predefine feature controls for that space. One of those templates can be an admin template, which enables all of the stack management and monitoring features. We can then disable those in the alternative recommended template that we’s anticipate admins using for most spaces they create.

In the future, space templates could be created by admins themselves to make managing large multi-space installs easier.

Edit: This feature would also make a big impact on our too-many-apps UX issue since it will encourage folks to limit the apps to what is necessary.

I think this is an interesting concept worth exploring. I'm thinking it'd require us to create a "Stack Management" feature which could be disabled using Spaces.

Prior to this discussion, we were intending to hide individual "stack management sections" based on the user's cluster privileges as detailed by #35965. We still have the option of continuing with this approach, and that's how I'm currently leaning.

[AlonaNadler]

I was looking on @cchaos mockups (thanks Caroline it is not easy to solve this), the mockups are great. it made me wonder whether we want the distinction and Kibana management to be around space vs non-space specific.

Capabilities that are cross spaces (not spaces specific):

• Elasticsearch management UI: rollups, index management, ILM, CCR, etc...

• Ingest configuration and management both for Logstash and Beats

• Monitoring of the stack

• Manage security - users/roles

• Manage objects across spaces

• Global setting - ATM mainly telemetry but in the future there might be more

• Future: list of all ML jobs

• Future: list of all alerting

Benefits of this change:

• Make distinction between what is space specific and what is non-space specific
• Helps manage objects (or ML jobs) between spaces in an easier way - without moving between spaces, showing all objects of all spaces
• Allows Kibana to hide management application entirely from end users or at least not show capabilities which require cluster privileges from end users.

This change made me wonder whether it needs to be only around management and around space specific vs nonspace specific or whether it should be an area for managing and monitoring the stack

Global vs specific space management approach or make a dedicated place with all capabilities for people who manage the stack and Kibana?

Focus on global vs specific space only:
Pros:

• Easy cut off of capabilities and tools which will be in this section of Kibana
• Currently limited number of capabilities

Cons:

• Might be too related to technical implementations, requires admins to educate themselves on what is spaces and no-space specific
• Most admins might look at Elasticsearch management capabilities as management of the stack unrelated to spaces
• Some admins tools will be in this special section while others will be in the spaces themselves (e.g. stack monitoring or dev tools) which will require admins who use both these tools to move between these areas of the product (feels like moving between spaces), for users it might feel like we created a dedicated area for admins while leaving some of the admins tools outside of this section

Making all admins tools in the same place: which means adding Stack monitoring to this initiative and calling it a place for the people who manage and monitor the stack.
Pros:

• All admins tools in one place - not only around space specific vs cross spaces
• Easier to explain, one place with all the dedicated tools to manage Kibana and the stack, or in short - manage and monitor the stack. The story is no longer around whether this feature space specific or not, which is a technical detail.

Cons:

• Likely a bigger change need to involve the stack monitoring team
• Not always clear what tools admins use and what should be available for others as well (e.g. dev tools, stack monitoring).

[kobelb]

@AlonaNadler, if I understand your comments correctly, you'd like to see "Stack Monitoring" and "Dev Tools" to be addressed with this reorganization, and preferably show up within whatever we call this "Admin Space". Is that correct? Is there anything else that you anticipate needing to be included?

[AlonaNadler]

Based on @cchaos im think it might make sense to add stack monitoring to this kibana management section. Regarding dev tools I'm not sure, I think dev tools have broader usage than just admins, what do you think @kobelb ?

Regarding my main concern, When spaces were introduced it also introduced the concept of space-specific and global, some of the things that are global are intentional (ES management capabilities) some of the things that are global are not intentional and driven by tech debt,

Since most of the intentional global capabilities are around the management of the stack it might make sense to wrap it as a dedicate place to manage Elastic stack which should include all the management capabilities as well as the monitoring of the stack.

[kobelb]

Regarding dev tools I'm not sure, I think dev tools have broader usage than just admins, what do you think @kobelb ?

I think it should likely be in both, as the usage is quite "broad".

With regard to your other comments @AlonaNadler, I agree.

[yaronp68]

Playing with @cchaos mockups. I like the general approach of removing space indicator and putting instead a global application name when going into management.
As @AlonaNadler mentioned there are also additional global application which is stack-monitoring.
Therefore, I would like to make the following suggestions:

• consider having management and monitoring as 2 links appearing on the top

• if possible, use another icon for space settings / space management (not the same cog wheel as for management)

• place the space setting link to the right on the top (where users typically look for settings and similar to panels on kibana dashboards)

• I agree that the DevConsole is not an admin only tool as it is used for any API execution, slow query analysis and other user actions on data

• See a benefit in placing navigation to management and monitoring in a higher location rather than at the bottom of the navigation bar, where sometimes even hidden by scroll
  I'd love to hear the thoughts of @elastic/stack-monitoring and @elastic/es-ui teams

[cjcenizal]

Would it make sense to just drop the user directly into the Kibana chrome, minus any space-specific apps? Maybe this replaces the Home page? (Or not, I haven't thought about the ramifications of changing the Home page so I'm just throwing it out there). Notice how the Space selection dropdown shows an empty space... some visual pun humor for you.

Then they could navigate around as usual (though notice that the Kibana apps are missing in Management):