Bedrud 实现了5层角色系统用于访问控制。每个角色映射到一组存储在用户记录中的访问字符串，并在 API 层（后端中间件）和 UI 层（前端守卫和条件渲染）强制执行。

角色层级

后端执行

访问级别通过每个管理路由上的 RequireAccess 中间件强制执行。中间件将用户的访问数组与所需的最低级别进行比对：

• 需要 superadmin 访问的路由拒绝管理员、版主、用户和访客
• 需要 admin 访问的路由允许超级管理员和管理员
• 需要 moderator 访问的路由允许超级管理员、管理员和版主

后端将访问权限以逗号分隔的字符串存储在数据库中（users 表的 accesses 列）。StringArray GORM 类型处理序列化和反序列化。

前端集成

用户类型

user.store.ts 中的 User 接口包含两个从访问数组派生的布尔字段：

interface User {
  // ...
  isSuperAdmin: boolean  // accesses.includes('superadmin')
  isAdmin: boolean       // accesses.includes('admin') || accesses.includes('superadmin')
  accesses: string[]     // raw access list from backend
}

管理守卫

管理布局（/dashboard/admin）允许超级管理员、管理员和版主通过。版主接收一个 isReadOnly=true 的上下文变量：

// routes/dashboard/admin.tsx
const canAccess = user?.isSuperAdmin || accesses.includes('admin') || accesses.includes('moderator')

useAdminContext() 钩子为所有子路由提供 isReadOnly 标志：

const { isReadOnly } = useAdminContext()

版主可查看 vs 可操作的内容

角色选择器

管理UI在用户列表表格和用户详情页面上都提供了一个 <Select> 下拉菜单，取代了之前的二进制超级管理员切换开关。可用选项：

下拉菜单发送一个包含完整访问数组的 PUT /api/admin/users/:id/accesses 请求。

CLI 管理

bedrud user promote 和 bedrud user demote 命令接受一个 --role 标志：

# Promote to superadmin (default)
bedrud user promote --email user@example.com
 
# Promote to admin
bedrud user promote --email user@example.com --role admin
 
# Promote to moderator
bedrud user promote --email user@example.com --role moderator
 
# Demote specific role
bedrud user demote --email user@example.com --role admin

有效的 --role 值：superadmin、admin、moderator、user、guest。

代码位置