The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Apr 8, 2026 2:38am

@BugBot review

PR Summary

Medium Risk
Automatically archiving all workspaces owned by a newly banned user (and deleting their API keys) is a destructive, cascading operation that runs on user updates, so misfires or partial failures could impact data availability and operational state.

Overview
Banning a user now triggers server-side cleanup: on user update, if user.banned is set, the system calls disableUserResources to archive every non-archived workspace the user owns (cascading to associated resources via workspace lifecycle) and delete the user’s personal API keys.

The admin user management UI is reworked to prevent action-button overlap by splitting each user row into a header row plus an inline “Confirm Ban” sub-row with an optional ban reason, and by toggling the Ban/Cancel state separately from the confirm action.

^{Reviewed by Cursor Bugbot for commit eb96a73. Bugbot is set up for automated code reviews on this repo. Configure here.}

@greptile review

Greptile Summary

This PR implements resource cleanup when a user is banned via the admin panel. It adds a disableUserResources function in lib/workflows/lifecycle.ts that archives all workspaces owned by the banned user (cascading to workflows, chats, forms, MCP servers, webhooks, etc.) and deletes their personal API keys. The ban logic is hooked into Better Auth's databaseHooks.user.update.after callback. It also fixes a UI layout issue in the admin panel where ban action buttons were overlapping other buttons by moving to a two-row layout.

Key observations:

• The update.after hook fires on every user record update, not just on the ban transition. Every time a banned user's record is updated, disableUserResources is called again.
• The fire-and-forget pattern means there is a brief window between when a ban is applied and when resources are actually cleaned up.
• Archiving owned workspaces cascades to all workspace members, not just the banned user.
• The isGithubAuthDisabled / isGoogleAuthDisabled flag removal is a follow-up cleanup (those flags were already removed from feature-flags.ts) — not a behavioral change.

Confidence Score: 4/5

Safe to merge with caution — two P1 logic issues should be addressed before relying on this in production for multi-workspace users.

The core intent is correct and workspace archiving idempotency makes repeated invocations harmless in the happy path. However, Promise.all short-circuit on failure is a real reliability gap for users with multiple workspaces, and the hook firing on every user update (not just the ban transition) is a latent correctness issue.

apps/sim/lib/workflows/lifecycle.ts (Promise.all vs allSettled) and apps/sim/lib/auth/auth.ts (update.after triggering on every update, not just ban transition)

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Admin bans user] --> B[BetterAuth updates user row]
    B --> C{update.after hook}
    C --> D{user.banned?}
    D -- No --> E[No-op]
    D -- Yes --> F[Call disableUserResources - fire and forget]
    B --> G[Ban confirmed to admin]

    F --> H[Query owned workspaces]
    H --> I[Promise.all]
    I --> J[archiveWorkspace for each]
    I --> K[Delete personal API keys]
    J --> L{Any promise rejected?}
    L -- Yes --> M[Outer catch logs error - remaining workspaces may stay active]
    L -- No --> N[All resources disabled]

_{Reviews (1): Last reviewed commit: "Fix lint" | Re-trigger Greptile}