Block replace/delete of SSO Owner in Modpanel

Jira: BIF-8750 · Epic: BIF-8695

Overview

Prevent an internal user from breaking the organization's SSO ownership from Modpanel. Replace of the SSO Owner is always blocked. Delete of the SSO Owner is conditional on billing status: blocked when the account is not on trial (is_trial = false), and allowed — behind an extra confirmation — when the account is still on trial (is_trial = true). Ownership is the source of truth maintained by the SSO Change Owner webhook (see sso-change-owner-webhook).

Scope Changes

• Backend — SSO Owner check via v1.1/users/me/current_company/application_owners; billing-status (is_trial) check gating the Delete branch.
• Frontend — block the Replace action; branch the Delete action on is_trial (block with error, or allow behind a confirmation popup).

8. User Stories + Acceptance Criteria

User Story	Importance	Mockup / Technical Notes	Acceptance Criteria
[SSOWN-S01] — Protect the SSO Owner from Replace As an internal user managing users in Modpanel, I want to be blocked from replacing a user who is the SSO Owner, so that I don't break the organization's SSO ownership.	Must Have	Owner check: v1.1/users/me/current_company/application_owners.	— Guard-rail — • NEG-1: Given an internal user attempts to Replace a user from Modpanel, when the target user is the SSO Owner, then the action is blocked and an error toast is shown. — Happy Path — • AC-1: Given the target user is not the SSO Owner, when Replace is attempted, then it proceeds as it does today. • AC-2: Given a Replace attempt, when determining SSO Owner status, then it is checked via v1.1/users/me/current_company/application_owners.
[SSOWN-S02] — Conditional Delete of the SSO Owner As an internal user managing users in Modpanel, I want Delete of the SSO Owner to be blocked when billing is live but allowed (with a confirmation) when the account is still on trial, so that I don't break SSO ownership for a paying customer while still being able to clean up trial accounts.	Must Have	Owner check: v1.1/users/me/current_company/application_owners. Billing check: is_trial. Block-error copy: "this user is SSO Owner, and billing status is not trial". Confirmation-popup copy: "this user is SSO Owner, are you sure you want to delete this user?".	— Guard-rail — • NEG-1: Given an internal user attempts to Delete a user from Modpanel, when the target user is the SSO Owner and is_trial = false, then the action is blocked and the error "this user is SSO Owner, and billing status is not trial" is shown. — Happy Path — • AC-1: Given an internal user attempts to Delete a user from Modpanel, when the target user is the SSO Owner and is_trial = true, then a confirmation popup with the warning "this user is SSO Owner, are you sure you want to delete this user?" is shown, and on confirm the deletion proceeds. • AC-2: Given the confirmation popup from AC-1, when the internal user cancels, then no deletion occurs. • AC-3: Given the target user is not the SSO Owner, when Delete is attempted, then it proceeds as it does today (no confirmation popup). • AC-4: Given a Delete attempt, when determining SSO Owner status, then it is checked via v1.1/users/me/current_company/application_owners.

Open questions

1. If the application_owners check is unavailable/errors, fail-closed (block) or fail-open (allow)? (Recommend fail-closed.)
2. Where is is_trial sourced for the Delete branch — same billing endpoint as the rest of Modpanel, and is it fresh at the moment of the Delete action?