Files

chihlasm 34daa26a67 feat: implement RBAC permissions system

Add role-based access control with hierarchy: super_admin > team_admin >
engineer > viewer. Adds is_super_admin boolean to User model (migration 010),
centralized backend permissions module, frontend usePermissions hook, and
UI enforcement (conditional Create/Edit buttons, editor redirect for viewers,
role badge in header). All endpoint admin checks updated from role=="admin"
to is_super_admin.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

2026-02-05 02:42:44 -05:00

3.6 KiB

Raw Permalink Blame History

RBAC Implementation - Flagged Questions & Context

Purpose

This document supplements Claude Code's RBAC implementation plan with questions and considerations for ResolutionFlow's multi-tenant SaaS architecture.

Multi-Tenant Model Overview

Account Tiers

Free/Individual — Single user, access to public trees only
Team Package — Team owner + invited members, private team trees + public trees

Content Visibility

Public Trees — ResolutionFlow official content, visible to all authenticated users
Team Trees — Created by team members, visible only to that team

Role Hierarchy

Role	Scope	Capabilities
Super Admin	System-wide	Manage public trees, all teams, all users
Team Owner	Their team	Everything Team Admin can do + billing management
Team Admin	Their team	Invite/remove members, assign roles, manage team trees
Engineer	Their team	Create/edit team trees & steps, fork public trees
Viewer	Their team	Read-only access to team + public trees, run sessions

Key Architectural Decisions

Database should support multi-team membership (junction table), but UI enforces single team for now
Team Owner is functionally a Team Admin with billing powers (no separate role needed initially)

Flagged Questions for Implementation

1. Step Library Permissions (Phase 2.5)

Can viewers rate/review steps, or is that engineer+ only?
How do ratings work across teams — are they global or team-scoped?

2. Session Permissions

Can viewers create new troubleshooting sessions, or only view past session history?
Clarify the intended behavior before implementing.

3. Personal Tree Branching (Phase 2.5)

When a user forks a public tree into their team's space, who owns it?
Does the original author get attribution, or is it a clean copy?

4. Team Content Isolation

The current plan references team_id but doesn't explicitly enforce that team trees are invisible to other teams.
Ensure build_tree_access_filter() and build_visibility_filter() account for:
- User's team membership
- Public vs team-private trees
- Cross-team isolation

5. Super Admin Role

The plan has "admin" but doesn't distinguish between "ResolutionFlow super admin" (system-wide) and "Team Admin" (team-scoped).
Consider: Should the database have an is_super_admin flag, or is this handled by a specific team/user ID?

6. Future Multi-Team Membership

The database should support users belonging to multiple teams (junction table) even if the UI enforces single-team for now.
Confirm the schema supports this or flag what migration would be needed later.

7. Subscription Lapse Handling (Low Priority - Not MVP)

What happens to team trees if a team subscription expires?
Options to consider:
- Team downgraded to viewer-only (can see but not edit)
- Grace period before content becomes inaccessible
- Export option before lockout
Not needed for MVP, but note where this logic would hook in.

Implementation Checklist

Before starting RBAC implementation, confirm answers to:

Session permissions: Can viewers create sessions or only view history?
Step ratings: Viewer participation yes/no?
Super admin flag: New DB field or handled differently?
Multi-team schema: Current schema supports this or needs migration?

Claude Code's original RBAC plan (see project knowledge)
Phase 2.5 roadmap (Step Library, Personal Branching)
CURRENT-STATE.md

Last updated: February 2025

3.6 KiB Raw Permalink Blame History