Project-based permissioning

[paolodamico]

Is your feature request related to a problem?

A recent focus customer has asked for some granular permissions related to projects. The basic use case is track multiple different properties (websites/apps) under the same account (organization), so each property would be under its own project, and be able to grant access to specific team members only to specific properties (i.e. projects).

Describe the solution you'd like

We could introduce the option of project access being available only to admins/owners by default and then for members you have to be assigned to a project specifically.

We could alternatively introduce the concept of private projects where only those with specific access in the org can see them.

Describe alternatives you've considered

See above.

Additional context

Tagging @Twixes here for input as he created most of the permissions engine.

This would certainly be a useful feature for large enterprise customers who need more granular controls due to privacy or compliance requirements.

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

[Twixes]

That's definitely possible and I was thinking about it when implementing organizations, but obviously more complexity involved. Would probably be best as an intermediary many-to-many ProjectMembership (for future per-project access levels) model. Probably worth taking a look at what Sentry have done in this area.

[clarkus]

Related: #3113

[marcushyett-ph]

From speaking to multiple customers about this type of permission issue these primary needs to solve for arose grouped by priority:

P0

• Admins must have access to every project
• Admins must be able to grant or revoke access to any project
• Users must have access to one or more projects
• During migration we must preserve current access rights of users to prevent the product breaking, until an administrator has granted appropriate access to users and enabled project level permissions

P1

• Some users should only have access to specific dashboards (within a project) assigned by an admin
• Roles (Authorization) to access projects should be assigned through SSO (e.g Active Directory Groups)
• [For some customers] Project members should be able to grant access to others to this project
• Organizational Admins should be able to administer the platform without seeing any data themselves

cc: @jamesefhawkins

[clarkus]

@marcushyett-ph that looks like a good list. Was there any thought given to allowing users to opt out of or leave organizations or projects?

[marcushyett-ph]

Great question.

I made one change above to say granting and revoking - to cover this. Revoking was only discussed from the point of view of admins, and not users revoking their own access to organizations.

Also where SSO is used, they would expect authorization to be kept in line with SSO groups - so if they're removed from the (e.g. Active Directory) group, then they should be removed form the associated projects automatically.

[paolodamico]

Per https://github.com/PostHog/product-internal/issues/142 this is ready to be worked on, so I think we can start getting ahead of the next sprint and start planning the solution / creating mockups (CC @clarkus) so we can get them in front of users before building it. @mariusandra / @Twixes I imagine you'd like to own this on the engineering side, thoughts?

[clarkus]

OK I will get started on this next week 👍

[Twixes]

Have we got any mocks on this? @clarkus

[clarkus]

@Twixes no not yet. I've been focused on paths. I can pick this up after #5543 though.