-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Project-based permissioning #4263
Comments
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 |
Related: #3113 |
From speaking to multiple customers about this type of permission issue these primary needs to solve for arose grouped by priority: P0
P1
cc: @jamesefhawkins |
@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? |
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. |
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? |
OK I will get started on this next week 👍 |
Have we got any mocks on this? @clarkus |
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!
The text was updated successfully, but these errors were encountered: