Allow for multiple projects to be viewed at the same time

[liyiy]

Is your feature request related to a problem?

Please describe.

Users would like to view more than one project at a time

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Thank you for your feature request – we love each and every one!

[neilkakkar]

Does this mean viewing more than one project at the same time? If not, how is it different from the existing setup (dropdown vs tab?).

Or, more broadly, what do the user get out of tabs? Ease of use? Quick access? Quickly loading saved funnels in different tabs? Something else?

[liyiy]

@neilkakkar What do you mean by existing setup? I think the user just wants to be able to have different projects up at the same time on various screens or side by side.

[paolodamico]

I was actually thinking about this a couple of days ago. What I was thinking of implementing is being able to send the Project ID with which you're working as a Header on every request and let the frontend handle the state of which project you're at. One thing I haven't reviewed is what backend parts that are isolated from a request require a project state to exist.

As this could potentially be quite complex and there doesn't seem to be a super strong need for it right now, I wonder if it's better to keep it on the back burner.

[liyiy]

A bug that's been resulting from this though is that currently we do allow users to open up multiple tabs with different projects each, just that it's really buggy and things don't load properly, so we might want to only allow one project opened per "session" at a time? (in however many tabs the user wants)

[KPdir]

I was actually thinking about this a couple of days ago. What I was thinking of implementing is being able to send the Project ID with which you're working as a Header on every request and let the frontend handle the state of which project you're at. One thing I haven't reviewed is what backend parts that are isolated from a request require a project state to exist.

As this could potentially be quite complex and there doesn't seem to be a super strong need for it right now, I wonder if it's better to keep it on the back burner.

Hi @paolodamico, I understand that "being able to view multiple projects" maybe complex. However, one thing that might be easier and would help avoid confusion for now is auto-refreshing all open connections for the user (tabs/ windows/browsers) or even just refreshing the project name to reflect the correct one i.e. the one for which the data is being shown. I posted some details around this in our internal Slack channel while talking to @liyiy.

[paolodamico]

My gut is that refreshing the project title only will not really prevent confusion, it can be easy to miss if you’re browsing multiple projects. Problem I see with refreshing everything else is that it can require almost the same amount of engineering effort as actually providing a solution for this, so maybe worth actually prioritizing a full fix for this. I’ll let @Twixes provide some context on this when he gets back as he built a big part of this engine, happy to pick it up if the solution makes sense.

[Twixes]

The problem is we're storing org and project selection state server-side, and the server only saves the state per user, not per browser tab – meaning if you have two tabs open and you switch org or project in one, the second will have weird inconsistencies or will fail until you reload it (thus going back to having the same project in both tabs).

This can be boiled down to two issues that need to be solved:

• #1343 – Without that being tackled, we are forced to rely on user.current_organization and user.current_team server-side, because the client's features are limited by API capabilities. Once the API is made capable though…
• this issue – Having made API routing sensible, we'd still be using current_* values initially (special ID @current), but then we would actually be able to introduce org/project selection stored client-side. There are two ways to go about this:
  1. state in localStorage - This would be really simple to implement, but only a partial improvement over server-side. A user would be able to successfully use different PostHog orgs/projects, but only with different browsers, and the state would be stashed away hidden from the user (so links would still fail for users having a diff org/project selected).
  2. state in the URL - This would require a revamp of frontend routing, but the UX would be ideal. Selection would be transparent, every tab could be a different org/project, sharing links would actually work. See a Sentry link for instance: https://sentry.io/organizations/posthog/issues/?project=5633355. In PostHog https://app.posthog.com/insights could be similarly replaced by something like https://app.posthog.com/posthog/app-plus-website/insights.

It'd be amazing to make any of the above a reality, because the current UX is pretty error-prone, but this would require some effort. I'd love to work on this but didn't get to prioritize it yet.

[benjackwhite]

Bumping as a reminder as customers (and Posthoggers) have complained about this again. Could be something solveable now

[clarkus]

Any reason we don't include the project ID in the URL to create permalinks? Seems like it'd solve for this, but also make it easier to share projects.