[Dashboard] Remove slugs for orgs

[svenefftinge]

We are moving away from orgs/teams being a secondary folder in which you maintain projects, towards orgs that act as a globally active context in which a user interacts with Gitpod. (see #15980 )

To that end it doesn't make sense to keep the slugs per org, instead we can allows a searchParam (in any dashboard URL) that will set the currently active org. The currently active org should be set in the browser session as well as in the settings, so that all existing APIs can obtain the active org if it is not passed explicitly (we can eventually move to explicitly passing the org as an argument).

Operations such as create workspace would use whatever context is set.
Starting existing workspaces should not use the global setting but restart the workspace in the org the workspace belongs to.

[gtsiolis]

This sounds more future-proof and flexible enough to break free from the structures that may exist in GitHub organizations, GitLab groups or sub-groups, etc. ✔️

@svenefftinge Does it make sense for projects and everything under a project (prebuilds, settings) to keep their URL?

☝️ In this or any case, is this a good opportunity to consider introducing a new path structure with prefixing everything with /-/? See #5516, #11510, and relevant discussions[1][2] (internal). Cc @corneliusludmann

{GITPOD_URL}/-/:project/:prebuild
{GITPOD_URL}/-/:billing
...

Possible use cases:

1. Having unique URLs for a project to anyone who can access it.
2. Having unique URLs for a project that could be public to instance users or the internet per setting.
3. Having unique URLs for prebuilds.

[svenefftinge]

I'm tempted to use the project id instead of a name/slug. That way we could tell users to switch to another org (and optionally don't ask again) if they are clicking a link to that project. Using the name there might be confusion if the same name is used in different orgs. wdyt?

[atduarte]

2 cents: What if we mix both? :D Similar to how Notion does it for example. {GITPOD_URL}/.../:id works but redirects to {GITPOD_URL}/.../:name-:id. It guarantees that the link points to the exact project, while providing visual aid to the user

[svenefftinge]

Sounds good! I would love to do that later once we feel like the URL needs to contain the project name as well? Seems like we could easily add such a redirect later. unlike notion, I believe the context in gitpod (i.e. project name) is very visible.

[gtsiolis]

Using the name there might be confusion if the same name is used in different orgs.

@svenefftinge DEAL 🤝—We've also run into duplicate naming issues in the past, see #6600 and #6883.

Unless it does not make sense or sound sane to do, maybe we could we also trim the IDs used for the URL to have shorter URLs when someone is visiting a project or a prebuild, for example:

// BEFORE 
https://gitpod.io/-/ef9d3f23-e5ab-4086-82f4-91813524bc3e/f4dc8d06-0ca1-4667-8467-e7d22b2ade79

// AFTER
https://gitpod.io/-/ef9d3f23/f4dc8d06

I would love to do that later once we feel like the URL needs to contain the project name as well?

+1

I believe the context in gitpod (i.e. project name) is very visible.

Indeed, this will be more visible with changes in #16046, see screenshots below. Cc @atduarte

BEFORE	AFTER

[atduarte]

@svenefftinge I'm ok with that. Notion adds the page title to the URL even though it's very visible when you open it. It helps when you have a list of links and want to know what is it about or for example you are sharing a link in Slack and want to make sure you are linking to the correct thing.

[svenefftinge]

I would not require the prebuilds to be a sub-resource of the project URLs if we use UUIDs.

[gtsiolis]

Sounds good—LET'S DO THIS. 🏀