Skip to content
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

[Spaces] Space Avatar with selector in main Kibana menu #18609

Merged
merged 9 commits into from
May 21, 2018

Conversation

legrego
Copy link
Member

@legrego legrego commented Apr 26, 2018

This adds a Global Nav Link to the main Kibana Menu, which will eventually show the currently selected space. It's currently a placeholder space until we can add the correct hooks to detect the active space.

Clicking the link will display a modal allowing the user to change their space.

Space Selection Screen

When security is enabled, this will appear after logging in. Without security, this will be the initial screen users see when navigating directly to Kibana, and not to an app within Kibana:
screen shot 2018-05-07 at 1 16 14 pm

Main Navigation

The bottom-left navigation region now shows the user's active Space. Clicking this will show a modal allowing them to switch spaces:

screen shot 2018-05-07 at 1 16 37 pm

Space Selection Modal

screen shot 2018-05-07 at 1 16 49 pm

Space Management

screen shot 2018-05-07 at 1 17 03 pm

Quick Visual Walkthrough

Sorry for the low-quality GIF 🥔
spaces-quick-demo

TODO:

  • Design Team UX 🎨

@legrego legrego added WIP Work in progress Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! labels Apr 26, 2018
@legrego legrego self-assigned this Apr 26, 2018
@legrego legrego requested a review from kobelb April 27, 2018 13:05
@legrego legrego mentioned this pull request May 3, 2018
3 tasks
@legrego legrego changed the title [Spaces WIP] Space Avatar with selector in main Kibana menu [Spaces] Space Avatar with selector in main Kibana menu May 3, 2018
@legrego legrego removed the WIP Work in progress label May 7, 2018
@@ -52,6 +54,42 @@ export const spaces = (kibana) => new kibana.Plugin({
const config = server.config();
validateConfig(config, message => server.log(['spaces', 'warning'], message));

if (!config.get('xpack.spaces.enabled')) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we shouldn't hit the init if the spaces plugin is disabled, so we should be able to remove this.

export class SpacesManager {
constructor(httpAgent, chrome) {
this._httpAgent = httpAgent;
this.chrome = chrome;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: it doesn't look like this is used after storing it at this.chrome, can we not store a reference to the chrome or rename it to this._chrome?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good catch, I'll fix this


async updateSpace(space) {
return await this._httpAgent
.post(`${this._baseUrl}/${space.id}?overwrite=true`, space)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason why are aren't using PUT for updates?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's an oversight - thanks!


async getActiveSpace() {
if (!this._activeSpace) {
this._activeSpace = await this._httpAgent
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an interesting approach, are we executing a full-page request after switching a space so that we clear this out?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking that we'd have to do a full page request after switching spaces. If we don't, then there are other implications, like changing the chrome service's basePath, and identifying any places where that might have been cached, such as the left nav bar.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that makes sense, sounds good!

return reply();
}

return reply(convertSavedObjectToSpace(spaces[0]));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we modify this to throw that Error that we talked about if we find more than one space that matches the url-context?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes We Can! 👍

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What should our behavior be when we detect this? Should a banner display at the top of the screen, should we redirect to the default space, or something else?

I don't think we should allow the user to stay in this Space, because we don't really know which space they intended to visit. If security wasn't an issue, then we could send them to the management screen, but not everybody will have access to it. We could also send them to a dedicated error page that explains what happened...maybe with a link to the management screen?

Similarly, what should the experience be when navigating to a space that doesn't exist?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most 500s from APIs will cause that toast notification that an error occurred, so doing the same thing here (if possible) makes sense to me. We do have a fatal error page that we could potentially use, but the toast notification is probably more consistent.

@kobelb
Copy link
Contributor

kobelb commented May 7, 2018

Also, the redirect that is occurring from the switching is just going to s/${spaceId} when there isn't a basepath, as opposed to a relative URL.

@legrego
Copy link
Member Author

legrego commented May 8, 2018

Also, the redirect that is occurring from the switching is just going to s/${spaceId} when there isn't a basepath, as opposed to a relative URL.

Great catch - I fixed this as well. Thanks!

@legrego legrego mentioned this pull request May 9, 2018
33 tasks
@rhoboat
Copy link

rhoboat commented May 10, 2018

The flow seems to work well. I'm curious what the design team thinks of a modal vs. another kind of visual motif. I'm curious whether the Delete Space has all the warnings one needs.

Which brings up: what happens when a space is deleted? Objects that were assigned to that space become global again?

(Edit: I think this is a better place for this discussion than #18862 because that is more about SOC than Spaces itself)

@legrego
Copy link
Member Author

legrego commented May 10, 2018

I'm curious what the design team thinks of a modal vs. another kind of visual motif.

Yeah I don't love the modal. The initial mockups had the space selector in a popover, but I ran into display & positioning issues in the left nav bar, so I swapped it out...at least temporarily. I wanted to get the rest of the PR functional and not churn on that in the short term.

@rhoboat
Copy link

rhoboat commented May 11, 2018

What about my main question?

@kobelb
Copy link
Contributor

kobelb commented May 11, 2018

The ability to delete a space and all related objects is the one of the main reasons why we scheduled the meeting this afternoon, so hopefully we'll have a better answer after this.

@legrego
Copy link
Member Author

legrego commented May 15, 2018

Here is the EuiPopover rendering "issue" that I mentioned above with the left nav bar:
popover fail

The Popover is constrained to the navbar area, and it doesn't seem possible to get it to "break free" and use the rest of the available space.
Maybe someone from @elastic/eui-design can weigh in here?

@legrego
Copy link
Member Author

legrego commented May 18, 2018

After talking with @kobelb, we decided in the interest of time that we can move forward with the Modal approach. If we would prefer the popover in the future, then we can perhaps reevaluate once we are on the new platform (where the left nav is Reactified)

@legrego
Copy link
Member Author

legrego commented May 18, 2018

@kobelb This is ready for your review. I haven't scheduled a design review yet, but I want to merge this to our feature branch so that I can move other work forward. I'll do the UI touchups as a separate PR.

I unfortunately scattered the tests across a couple of different PRs, so it's hard to see right now what has tests and what doesn't. In any event, I plan on adding more tests once I have these PRs merged together.

Copy link
Contributor

@kobelb kobelb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great, one concern with our callWithInternalUser usage, but besides that it's looking good.

};
}

const callWithInternalUser = getClient(server).callWithInternalUser;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm assuming it's not possible to use the SavedObjectsClient here? We shouldn't be using callWithInternalUser at least, as this has the potential to grant unauthorized users permission to the spaces... using callWithRequest is at least safer, but the SavedObjectClient is preferable (unless we can't do so until the Client/Repository split actually happens).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I did this right, callWithInternalUser should only be used within checkForDuplicateContext, which tries to prevent two Spaces from existing with the same urlContext. To do that correctly, I need to bypass the security and space filters that exist on the SavedObjectsClient.

So the short answer is "we can't do so until the Client/Repository split actually happens"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gotcha, that makes sense. As long as we have it noted that we'll need to switch this in the future, LGTM

Copy link
Contributor

@kobelb kobelb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@legrego legrego merged commit 50c73b4 into elastic:spaces-phase-1 May 21, 2018
@legrego legrego deleted the space-avatar branch April 29, 2019 14:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants