Fix SSO_ONLY users unable to accept org invites (#7072)#7079
Fix SSO_ONLY users unable to accept org invites (#7072)#7079pmhnam wants to merge 1 commit intodani-garcia:mainfrom
Conversation
There was a problem hiding this comment.
Pull request overview
This PR addresses a gap in the organization invitation flow where SSO_ONLY users (no master password) can’t complete the email-based invite acceptance step, by auto-accepting invites for already-existing SSO_ONLY users so an admin can proceed to the confirmation step.
Changes:
- Auto-accept organization invitations for existing
SSO_ONLYusers during invite creation. - Auto-accept invitations for
SSO_ONLYusers during the reinvite flow (and clear any stored invitation).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
SSO_ONLY users have no master password and cannot use the email-based invite acceptance flow. This change auto-accepts organization invitations for SSO_ONLY users who already exist, allowing them to proceed directly to the confirmation step by an admin. Fixes dani-garcia#7072
pmhnam
force-pushed
the
fix/sso-only-org-invite-7072
branch
from
69899a6 to
994ee0d
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // Only send the invite email if the member is still in the Invited state. | ||
| // SSO_ONLY users are auto-accepted above and should not receive an invite | ||
| // email with a link they cannot use. | ||
| if CONFIG.mail_enabled() && member_status == MembershipStatus::Invited as i32 { |
There was a problem hiding this comment.
When member_status is force-set to Accepted (e.g., for SSO_ONLY users), the org policy checks that normally run during acceptance (OrgPolicy::check_user_allowed, see src/api/core/mod.rs:275+) are bypassed here. This can leave members in Accepted state even if 2FA/SingleOrg policies would forbid joining. Consider running OrgPolicy::check_user_allowed before persisting an Accepted status (or otherwise ensuring policies are enforced at this transition).
| let mut member = member; | ||
| member.status = MembershipStatus::Accepted as i32; | ||
| member.save(conn).await?; |
There was a problem hiding this comment.
This auto-accept path sets member.status = Accepted without enforcing OrgPolicy::check_user_allowed (2FA / SingleOrg). The regular acceptance flow enforces these policies; consider applying the same check here before saving the updated membership status.
Summary
Fixes #7072
SSO_ONLY users (users who authenticate via SSO and have no master password) cannot accept organization invites because the invite acceptance flow requires a master password login.
Changes
send_invite: Auto-set membership status toAcceptedfor existing SSO_ONLY users when they are invited to an organization_reinvite_member: Prioritize SSO_ONLY auto-accept before attempting to send an email invite that the user cannot act onHow it works
When
SSO_ENABLED=trueandSSO_ONLY=true, users who have an emptypassword_hash(indicating they authenticated only via SSO) are automatically moved toAcceptedstatus when invited. The admin can then confirm them normally through the admin console.Testing