Bedrud はアクセス制御のための5段階ロールシステムを実装しています。各ロールはユーザーレコードに保存されたアクセス文字列のセットにマッピングされ、API層（バックエンドミドルウェア）とUI層（フロントエンドガードと条件付きレンダリング）の両方で適用されます。

ロール階層

バックエンドでの適用

アクセスレベルは、すべての管理ルートで RequireAccess ミドルウェアを介して適用されます。ミドルウェアは、ユーザーのアクセス配列を必要な最小レベルと照合します：

• superadmin アクセスが必要なルートは、管理者、モデレーター、ユーザー、ゲストを拒否
• admin アクセスが必要なルートは、スーパー管理者と管理者を許可
• moderator アクセスが必要なルートは、スーパー管理者、管理者、モデレーターを許可

バックエンドはアクセスをカンマ区切りの文字列としてデータベースに保存します（users テーブルの accesses カラム）。GORM の StringArray 型がシリアライズとデシリアライズを処理します。

フロントエンド連携

ユーザータイプ

user.store.ts の User インターフェースには、アクセス配列から派生した2つのブール型フィールドが含まれています：

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。

コードの場所