mobile-rbac（移动 RBAC）

Platform Notes

• Optional helper plugins may help in some environments, but they must not be treated as required for this skill.

Mobile RBAC - Android Permission System

Use When

• Role-Based Access Control for Android mobile apps integrating with a multi-tenant SaaS backend. Covers permission fetching, caching in EncryptedSharedPreferences, Jetpack Compose permission gates (PermissionGate, ModuleGate, PermissionButton)...
• The task needs reusable judgment, domain constraints, or a proven workflow rather than ad hoc advice.

Do Not Use When

• The task is unrelated to mobile-rbac or would be better handled by a more specific companion skill.
• The request only needs a trivial answer and none of this skill's constraints or references materially help.

Required Inputs

• Gather relevant project context, constraints, and the concrete problem to solve; load references only as needed.
• Confirm the desired deliverable: design, code, review, migration plan, audit, or documentation.

Workflow

• Read this SKILL.md first, then load only the referenced deep-dive files that are necessary for the task.
• Apply the ordered guidance, checklists, and decision rules in this skill instead of cherry-picking isolated snippets.
• Produce the deliverable with assumptions, risks, and follow-up work made explicit when they matter.

Quality Standards

• Keep outputs execution-oriented, concise, and aligned with the repository's baseline engineering standards.
• Preserve compatibility with existing project conventions unless the skill explicitly requires a stronger standard.
• Prefer deterministic, reviewable steps over vague advice or tool-specific magic.

Anti-Patterns

• Treating examples as copy-paste truth without checking fit, constraints, or failure modes.
• Loading every reference file by default instead of using progressive disclosure.

Outputs

• A concrete result that fits the task: implementation guidance, review findings, architecture decisions, templates, or generated artifacts.
• Clear assumptions, tradeoffs, or unresolved gaps when the task cannot be completed from available context alone.
• References used, companion skills, or follow-up actions when they materially improve execution.

Evidence Produced

References

• Use the references/ directory for deep detail after reading the core workflow below.

Architecture Overview

Mobile RBAC uses a hybrid client+server approach:

1. Backend enforces - Every API call checked by PermissionMiddleware (returns 403 if denied)
2. Client gates UI - Cached permissions control button/tab/screen visibility for UX
3. Fail-secure - If permissions unknown, deny access (never grant)
4. Offline-capable - Cached permissions work without network

Backend Environments: Dev (Windows/MySQL 8.4.7), Staging (Ubuntu/MySQL 8.x), Production (Debian/MySQL 8.x). Permission APIs must behave identically across all environments. Use Gradle build flavors for environment-specific base URLs.

Login → Fetch Permissions → Cache in EncryptedSharedPreferences → UI Gates
         ↕ (refresh)                                                ↕ (403 fallback)
     Backend always enforces ←──────────────────────────────────────┘

Quick Reference

Core Principles

1. Two-Layer Gating

Rule: Modules HIDE tabs entirely. Permissions DISABLE or HIDE individual actions.

2. Permission Resolution (Backend)

The backend resolves permissions using 5-tier priority:

1. User Denial  (explicit deny)    → ALWAYS DENIED
2. User Grant   (explicit grant)   → ALWAYS GRANTED
3. Franchise Override              → Tenant customization
4. Role Permission                 → Default from role
5. Super Admin / Owner             → ALL permissions

The mobile client never resolves permissions locally. It receives the resolved set from the backend via GET /user/permissions and uses it as-is.

3. Storage: EncryptedSharedPreferences

Permissions are a flat set of ~20-50 string codes. Too lightweight for Room.

"user_permissions"    → Set<String> {"POS_CREATE_SALE", "DASHBOARD_VIEW", ...}
"user_modules"        → Set<String> {"POS", "INVENTORY", ...}
"user_roles"          → Set<String> {"CASHIER", ...}
"user_type"           → String "staff"
"permissions_updated" → Long (epoch millis)

4. Refresh Strategy

5. Offline Behavior

• Use cached permissions (last known good)
• If no cache exists (fresh install), deny all
• Never allow more access offline than last sync granted

PermissionManager (Singleton)

The central permission store, injected via Hilt:

@Singleton
class PermissionManager @Inject constructor(
    @ApplicationContext context: Context
) {
    // StateFlow for Compose reactivity
    val permissionsFlow: StateFlow<Set<String>>
    val modulesFlow: StateFlow<Set<String>>

    // Checks
    fun hasPermission(code: String): Boolean
    fun hasAnyPermission(codes: Collection<String>): Boolean
    fun hasAllPermissions(codes: Collection<String>): Boolean
    fun hasModule(code: String): Boolean
    fun isOwner(): Boolean
    fun isSuperAdmin(): Boolean
    fun isStale(): Boolean

    // Storage
    fun savePermissions(permissions: Set<String>)
    fun saveModules(modules: Set<String>)
    fun clear() // Call on logout
}

Owner and Super Admin bypass all permission checks. Check user_type first.

UI Patterns

Pattern 1: PermissionGate (Show/Hide)

@Composable
fun PermissionGate(
    permissionManager: PermissionManager,
    permission: String,
    hide: Boolean = true,          // true = render nothing when denied
    deniedContent: @Composable (() -> Unit)? = null,
    content: @Composable () -> Unit
)

Use for: FABs, action buttons, cards, sections that should be completely hidden if the user lacks permission.

Icon Policy: Use custom PNG icons only; follow android-custom-icons and update PROJECT_ICONS.md.

Report Table Policy: If permissioned screens include reports that can exceed 25 rows, use table layouts (see android-report-tables).

// Hide "Create PO" FAB if user can't create POs
PermissionGate(permissionManager, Permission.INVENTORY_PO_CREATE) {
    FloatingActionButton(onClick = onCreatePO) {
        Icon(painterResource(R.drawable.add), "Create PO")
    }
}

Pattern 2: PermissionButton (Disable with Message)

@Composable
fun PermissionButton(
    permissionManager: PermissionManager,
    permission: String,
    onClick: () -> Unit,
    text: String,
    deniedMessage: String = "You don't have permission"
)

Use for: Primary actions that users should SEE but can't perform (approve, dispatch, receive, charge).

// "Approve" button - visible but disabled if no permission
PermissionButton(
    permissionManager = permissionManager,
    permission = Permission.INVENTORY_PO_APPROVE,
    onClick = { viewModel.approve() },
    text = "Approve",
    deniedMessage = "Approval restricted"
)

Pattern 3: ModuleGate (Tab Visibility)

@Composable
fun ModuleGate(
    permissionManager: PermissionManager,
    module: String,
    content: @Composable () -> Unit
)

Use for: Bottom navigation tabs, entire feature sections.

// Filter bottom nav items by module access
val items = buildList {
    add(BottomNavItem.Dashboard) // Always visible
    if (permissionManager.hasModule(Module.POS)) add(BottomNavItem.POS)
    if (permissionManager.hasModule(Module.INVENTORY)) add(BottomNavItem.Inventory)
    add(BottomNavItem.Settings) // Always visible
}

Pattern 4: Navigation Guard

// In NavHost: guard sensitive routes
composable("create_purchase_order") {
    if (permissionManager.hasPermission(Permission.INVENTORY_PO_CREATE)) {
        CreatePurchaseOrderScreen(...)
    } else {
        PermissionDeniedScreen(
            permission = "Create Purchase Orders",
            onBack = { navController.popBackStack() }
        )
    }
}

Pattern 5: PermissionDeniedScreen

Full-screen blocker for navigation guards:

@Composable
fun PermissionDeniedScreen(
    permission: String,    // Human-readable name
    onBack: () -> Unit
)
// Shows: Lock icon + "Access Restricted" + explanation + "Go Back" button

UX Guidelines

Backend Integration

API Endpoint: GET /user/permissions

{
    "success": true,
    "data": {
        "user_id": 10014,
        "franchise_id": 3,
        "user_type": "staff",
        "roles": [{"code": "CASHIER", "name": "Cashier"}],
        "permissions": ["DASHBOARD_VIEW", "POS_CREATE_SALE", ...],
        "modules": [
            {"code": "POS", "name": "Point of Sale", "is_enabled": true},
            {"code": "INVENTORY", "name": "Inventory", "is_enabled": false}
        ]
    }
}

403 Response Handling

{
  "success": false,
  "message": "You do not have permission to perform this action",
  "error": {
    "code": "PERMISSION_DENIED",
    "required_permission": "INVENTORY_PO_APPROVE"
  }
}

Client response:

1. Parse required_permission from error
2. Auto-refresh permissions via /user/permissions
3. Show friendly message: "Your permissions have been updated"

CompositionLocal (Convenience)

val LocalPermissionManager = staticCompositionLocalOf<PermissionManager> {
    error("No PermissionManager provided")
}

// In MainScaffold:
CompositionLocalProvider(LocalPermissionManager provides permissionManager) {
    // All child composables access via LocalPermissionManager.current
}

Security Rules

1. Never trust client-only checks - Backend ALWAYS validates permissions
2. Encrypted storage - Use EncryptedSharedPreferences, never plain SharedPrefs
3. Clear on logout - permissionManager.clear() in logout flow
4. Franchise isolation - Permissions scoped to franchise_id in JWT
5. No permission codes in logs - Don't log full permission sets

Integration with Other Skills

dual-auth-rbac (backend) → Defines permission tables, resolution logic, middleware
      ↓
mobile-rbac (THIS SKILL) → Android-specific permission caching, UI gates, offline
      ↓
jetpack-compose-ui → PermissionGate composables follow Material 3 patterns
      ↓
android-development → Hilt DI, MVVM, Clean Architecture integration

Anti-Patterns