Revised navigation: org selection behavior

[jduss4]

Provide the user with the ability to switch organizations when they have access to more than one. This issue is partially blocked by UI work, but backend logic can be worked on in advance.

Implementing this design will require us to make a decision about how / where to store the currently selected organization (local storage? url? location in the app?).

We will also have to consider what happens after an organization is selected. Will the user be sent to the organization's main page?

• Partially blocked by #409
• Partially blocked by #408

Acceptance Criteria

• [ ] User can see their currently selected organization
• [ ] User can switch to another organization

[echappen]

If the org ID is in the path/route, then we can make a request for the org info on page load like we're already doing, and the org switcher would just be hyperlinks to different org routes. This would be the simplest path forward, and I don't see any benefits to keeping an org ID elsewhere in the app.

@hursey013 @jduss4 Is there any reason to not keep the org ID in any path/route that pertains to a specific org? For example, doing /orgs/1/applications or /orgs/1/users/5 instead of /applications or /users/5. It seems like all CF information depends on what org you're in.

[echappen]

As for the switching behavior: if we wanted to keep the user on the same type of page when switching orgs, I could see a routine where we get 1) a list of all org ID's available to this user, and 2) the current path, then make a list of urls for that path for each org ID. For example, if the current page is the users list, then the list of hyperlinks for the org switcher would look like:

/orgs/1/users
/orgs/2/users
/orgs/3/users

[jduss4]

The only things that come to mind for me are if we want to kinda "save" the most recent org a user interacted with, so that auto-loads up when they return to cloud.gov or if they wander to non-org pages (like user settings or something) and we want to have links in the nav that just go to something like "applications" that assume an organization context. Prioritizing that type of behavior is probably a design question, though.

Otherwise, I think leaving orgs in links makes the most sense to me, as it also gives users the ability to send each other links that will behave predictably.

Re: switching -- I'm not sure what would be best here.. At a glance it makes sense to me to swap in the same URL for a different org, but I think this could get tricky as we create pages that are unique to each org (like a space detail page, or user detail page, app, etc). On the other hand, I can also see it being confusing if they got booted back to the main org page. The latter seems like the easiest thing to implement for now?

[echappen]

This seems more like a design/UX decision at this point. Options are: 1) Org switcher switches to current page, but different org 2) Org switcher switches to main org page (i.e. the users list) for a different org

@hursey013 or @beepdotgov I'd like to start with option 2 since it's the simpler one, unless either of you see a compelling reason for option 1. Any objections?

[beepdotgov]

UX-wise, option 1 feels like the more intuitive option, but I agree with @jduss4’s point: some pages simply won’t exist across orgs.

Just thinking through this a bit: is there a way to tweak option 1 a little? I’m wondering if it’d be possible that, when a user switches to a new org, they land on the top-level page of the section (user management, billing, &c) they were just in? So if I’m in:

/orgs/2/billing/view/[invoice id]

moving to a different org would navigate me to

/orgs/1/billing

If that’s not possible, I’m totally fine with option 2! Especially if it’s a quicker path to getting something into the prototype, and in front of users for testing.

[echappen]

@beepdotgov That seems doable to me—thanks!

[beepdotgov]

Thanks for asking! Excited to see this in action 🚀

[echappen]

Blocked by #409