Automatically switch to the right project if possible

[Twixes]

Changes

Sometimes you get sent a link to PostHog that points to an item from a different project than the one you are currently in. Right now this results in a 404. With this solution, if you have access to the target project, you'll be seamlessly switched to it.

This was kind of tackled already by the solution from #8262, but that required user interaction and worked only for dashboards. This solution instead "asks for forgiveness" (which seems to be the more intuitive choice here) and works for dashboards, insights, feature flags, actions, and cohorts.

Note that this does not fix using multiple projects at once (#5363), nonetheless it's a significant improvement to the experience of using multiple projects.

How did you test this code?

Added a bunch of cases to test_middleware.py (TestAutoProjectMiddleware).

[clarkus]

Looks good to me. We might consider a toast instead of the banner. That would have the benefit of being lower priority, dismissing automatically, while still offering a prominent undo or go back action that helps the user recover just in case this was a navigational error. The key thing to communicate is that the user is in a new context - "you've switched to project ABC". Not so much why it happened, just that it did and that there is an easy way to go back. Thoughts?

[Twixes]

That's some good points, +1 on autodismiss and being less verbose – a toast sounds like a good solution. But I'm not sure what should it look like – our toast are kind of all over the place currently, and I don't think we have a good pattern for info-level ones (as opposed to the more common success/error).

[Twixes]

Currently looks like this:

[clarkus]

Here's a work-in-progress toast design in two variations. Thoughts on either option?

[Twixes]

The light one looks pretty great (black seems extremely contrasty compared to the rest of the app).
One thought is that "Undo" is pretty ambiguous, plus a user is quite likely to not remember what project they'd be switching back to. My proposal is "Switch back to <previous project>", though that could require putting the button below the text.

[clarkus]

The light one looks pretty great (black seems extremely contrasty compared to the rest of the app). One thought is that "Undo" is pretty ambiguous, plus a user is quite likely to not remember what project they'd be switching back to. My proposal is "Switch back to ", though that could require putting the button below the text.

Agree with the approach. Naming where they're returning to would be great, but it's going to eat up a lot of space. We could say "go back" instead of "undo"? It would achieve the same intent but in fewer characters.

[hazzadous]

@Twixes I don't have much context on this, but could we just encode the organization and project into the url and remove the state we're storing on the user db model altogether? Or is this something we have considered and rejected for some reason?

[Twixes]

Absolutely @hazzadous, that's the next step which will solve the multiple projects at once case. The difference is that this is a single middleware with some notification code, while putting the project in the URL will take updating many logics in the frontend and ensuring a backwards compatibility layer.

[hazzadous]

@Twixes do you know when the next steps are likely to happen?

[mariusandra]

Looks great to me!

@hazzadous the project ID is already embedded in the URL, just behind a foreign key relationship:

• http://localhost:8000/insights/SVEEYnLs
• http://localhost:8000/insights/Gp1vl2Yo
• http://localhost:8000/feature_flags/5
• http://localhost:8000/feature_flags/8

In these cases, if the user has access to the object they're trying to open, we can just swap the project behind the scenes when opening the URL... as that's very likely what they're trying to do.

We'll theoretically only need the project ID in the URLs if we ever want to share index pages like:

• http://localhost:8000/projects/PROJECT_ID/feature_flags

Putting this in the URL has been suggested as the correct implementation for this task, but that has been a pending/stalling todo item for months now, so there's some friction in getting this going. Personally I think we can stall longer, as the problem has always been about opening a certain insight/dashboard that are shared with you, not settings pages. This PR solves that beautifully.

Having two projects in two tabs side by side in one browser will still have some issues and requires rewriting some API calls. That'll be the next step to work on here... and finally we can see if making all URLs in posthog longer by adding a project ID is worth the tradeoff in friendliness.

[Twixes]

Merged with that basic toast, I'm making a separate PR to overhaul the toast patterns.