Skip to content
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

feat: update organization member abilities #27232

Merged
merged 6 commits into from
Jan 8, 2025
Merged

feat: update organization member abilities #27232

merged 6 commits into from
Jan 8, 2025

Conversation

zlwaterfield
Copy link
Contributor

@zlwaterfield zlwaterfield commented Jan 3, 2025

Changes

Related to upcoming RBAC changes, follow along #24512.

This PR is updating the abilities of an organization member to be more restrictive - we're moving to a model where users will need to be organization admins or owners to perform organization-level changes. This change is opinionated - it's meant to apply a new level of thinking of what a member should be able to do - which is very little at the organization level. This change is being made in line with the RBAC to allow organizations to control better who can do what within their PostHog organization.

These changes are only being made on the client side, there will be a subsequent PR to also check these serverside.

posthog.com docs change: PostHog/posthog.com#10246

Changes (things members can no longer do)

  • access the billing page
  • alter managed reverse proxies
  • alter authenticated domains (sso, saml, jit, etc.)
  • manage members (delete invites)
  • change the organization name or logo
  • manage roles (old feature flag RBAC)

I will post this in Slack and let everyone know if they receive support requests related to this change. We can recommend users update member roles to admin for those who need to access features we've changed.

In the future:

  • Originally, I had send team invites in this PR, but I wound that back because we want to think more about this change since it affects how many people can get into an organization on PostHog. We may layer this back on as a configurable property by the organization admins - maybe as a feature on the teams add-on.
  • I hope we can make these configurable to give a better experience to users, but this is a step in the right direction.
  • This doesn't restrict project settings but we should probably do that as well. I will talk to a few teams and see what they think about that.

👉 Stay up-to-date with PostHog coding conventions for a smoother review.

Does this work well for both Cloud and self-hosted?

Yes

How did you test this code?

Test manually

@zlwaterfield zlwaterfield self-assigned this Jan 3, 2025
@zlwaterfield zlwaterfield changed the title Update access levels to org features feat: update organization member abilities Jan 3, 2025
@zlwaterfield zlwaterfield requested review from Twixes, raquelmsmith, timgl, benjackwhite and patricio-posthog and removed request for Twixes January 3, 2025 00:30
Copy link
Contributor

github-actions bot commented Jan 3, 2025

Size Change: 0 B

Total Size: 1.11 MB

ℹ️ View Unchanged
Filename Size
frontend/dist/toolbar.js 1.11 MB

compressed-size-action

@posthog-bot
Copy link
Contributor

📸 UI snapshots have been updated

2 snapshot changes in total. 0 added, 2 modified, 0 deleted:

  • chromium: 0 added, 2 modified, 0 deleted (diff for shard 1)
  • webkit: 0 added, 0 modified, 0 deleted

Triggered by this commit.

👉 Review this PR's diff of snapshots.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the reason for making it so that members cannot invite new members generally? Since we don't charge for seats I don't think this is a good idea. Getting more people into posthog is always better, and bottlenecking that through admins and owners is probably a bad thing?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I've went back and forth on this. Generally it's not great practice to allow anyone to join your organization but I agree with you. I think I'll wind this back to how it is today and on another PR add a configurable option for organizations to set this - could be a teams add-on feature. We've had multiple customers ask for limiting who can invite.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated - there are no changes on this PR for sending invites, although it still blocks deleting invites.

Copy link
Member

@raquelmsmith raquelmsmith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing blocking, just some suggestions, up to you if you want to address

Comment on lines +16 to +17
/** Whether input field is disabled */
disabled?: boolean
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Our pattern is usually disabledReason to force someone to give a reason why something is disabled, which is a better user experience. Should we follow that pattern?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Disabled reason looks to be used for buttons and such but just disabled on inputs because we don't show the tooltip on those.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, just wondering if we should change that

frontend/src/scenes/billing/Billing.tsx Show resolved Hide resolved
frontend/src/scenes/settings/organization/Invites.tsx Outdated Show resolved Hide resolved
@@ -46,7 +53,7 @@ export function SSOSelect({ value, loading, onChange, samlAvailable }: SSOSelect
value={value}
options={options}
loading={loading}
disabledReason={loading ? 'Cannot change while loading' : undefined}
disabledReason={loading ? 'Cannot change while loading' : disabledReason}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this component not handle disabling while loading? I kinda figure it would since it has the loading prop. if not, it probably should?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does, but this is just adding a tooltip over it while it's loading. The loading props just disables it, doesn't give a tooltip.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, might be worth changing, so if no reason it just says "loading..." Otherwise can override if you want a custom loading message with disabledReason

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm hestitant to make changes that affect such a high number of parts of the app - that would make it so anytime a button is loading there is a tooltip over it showing text (the LemonSelect uses LemonButton).

I think it's better to have a more explicit option like this for when you actually want a tooltip.

@zlwaterfield zlwaterfield merged commit 2f4fe25 into master Jan 8, 2025
99 checks passed
@zlwaterfield zlwaterfield deleted the zach/rbac/8 branch January 8, 2025 22:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants