Keep an account's only owner from deactivating themself

[jeremy]

An account's owner could deactivate themself by replaying the remove-person request with their own user id. The UI never offers it (the remove button is disabled for yourself), but UsersController#destroy is gated by can_change?, whose other == self arm admits the owner. The result is an account with no owner and no way to get one back: nobody left can cancel the account or change settings, and rejoining via join code creates a fresh member. Surfaced by a bug bounty report; closed as self-exploitation, but it is a foot-gun worth removing.

Change

• User#sole_owner?: the user is an active owner and the account has no other active owner.
• UsersController#destroy refuses when the target is the sole owner: HTML redirects to account settings with an alert, JSON responds 422 Unprocessable Entity. The check runs after the existing permission gate, so an admin trying to remove the owner is still 403 Forbidden.
• API docs list the 403 and 422 responses for DELETE /:account_slug/users/:user_id.

What stays the same

• Admins and members can still deactivate themselves (intentionally allowed).
• An owner can still deactivate themself if the account has another active owner.
• User#deactivate is untouched. Identity#before_destroy deactivates every user of the identity, owners included, and that path must keep working, so the rule sits at the request boundary rather than inside the model operation.

Not done on purpose

• No lock against two owners of the same account racing to remove themselves at once. Only they can produce that state, against their own account, and the app has no way to create a second owner today.
• No transfer-ownership affordance. Separate feature.

Tests

• Owner removing themself as the only owner: refused (HTML redirect with alert, JSON 422), still active, still the account's owner.
• Owner removing themself with a second owner present: allowed.
• Admin and member removing themselves: allowed.
• Admin removing the owner: still 403.
• sole_owner? across owner/admin/member, a second owner, and a deactivated second owner.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-10T10:12:36.128704Z	7e4b5e5	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[Copilot]

🟡 Changes recommended

sole_owner? currently misclassifies inactive users as sole owners.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Prevents an account’s sole owner from deactivating themself through the users endpoint.

Changes:

• Adds sole-owner detection and controller enforcement.
• Covers HTML/JSON behavior and role scenarios.
• Documents new API error responses.

[!TIP]
If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.

File summaries

File	Description
app/models/user/role.rb	Adds sole-owner detection.
app/controllers/users_controller.rb	Blocks sole-owner deactivation.
test/models/user/role_test.rb	Tests owner-role scenarios.
test/controllers/users_controller_test.rb	Tests deactivation outcomes.
docs/api/sections/users.md	Documents 403 and 422 responses.

Review details

• Files reviewed: 5/5 changed files
• Comments generated: 1
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.