PR Body Implements Spec 065 “Tenant RBAC v1” with capabilities-first RBAC, tenant membership scoping (Option 3), and consistent Filament action semantics. Key decisions / rules Tenancy Option 3: tenant switching is tenantless (ChooseTenant), tenant-scoped routes stay scoped, non-members get 404 (not 403). RBAC model: canonical capability registry + role→capability map + Gates for each capability (no role-string checks in UI logic). UX policy: for tenant members lacking permission → actions are visible but disabled + tooltip (avoid click→403). Security still enforced server-side. What’s included Capabilities foundation: Central capability registry (Capabilities::*) Role→capability mapping (RoleCapabilityMap) Gate registration + resolver/manager updates to support tenant-scoped authorization Filament enforcement hardening across the app: Tenant registration & tenant CRUD properly gated Backup/restore/policy flows aligned to “visible-but-disabled” where applicable Provider operations (health check / inventory sync / compliance snapshot) guarded and normalized Directory groups + inventory sync start surfaces normalized Policy version maintenance actions (archive/restore/prune/force delete) gated SpecKit artifacts for 065: spec.md, plan/tasks updates, checklists, enforcement hitlist Security guarantees Non-member → 404 via tenant scoping/membership guards. Member without capability → 403 on execution, even if UI is disabled. No destructive actions execute without proper authorization checks. Tests Adds/updates Pest coverage for: Tenant scoping & membership denial behavior Role matrix expectations (owner/manager/operator/readonly) Filament surface checks (visible/disabled actions, no side effects) Provider/Inventory/Groups run-start authorization Verified locally with targeted vendor/bin/sail artisan test --compact … Deployment / ops notes No new services required. Safe change: behavior is authorization + UI semantics; no breaking route changes intended. Co-authored-by: Ahmed Darrazi <ahmeddarrazi@MacBookPro.fritz.box> Reviewed-on: #79
33 lines
1.4 KiB
Markdown
33 lines
1.4 KiB
Markdown
# Data Model: Tenant RBAC v1
|
|
|
|
This document outlines the data model for the Tenant RBAC feature, as defined in the feature specification.
|
|
|
|
## Tables
|
|
|
|
### `tenant_memberships` (New Table)
|
|
|
|
This table is the source of truth for user membership and roles within a tenant.
|
|
|
|
**Columns**:
|
|
|
|
| Name | Type | Description | Constraints |
|
|
|---|---|---|---|
|
|
| `id` | `bigint` or `uuid` | Primary key. Follows repository convention. | Primary Key |
|
|
| `tenant_id` | `bigint` | Foreign key to the `tenants` table. | Not Null, FK to `tenants.id` |
|
|
| `user_id` | `bigint` | Foreign key to the `users` table. | Not Null, FK to `users.id` |
|
|
| `role` | `string` | The user's role within the tenant. | Not Null, Enum: `owner`, `manager`, `operator`, `readonly` |
|
|
| `created_at` | `timestamp` | Timestamp of creation. | Not Null |
|
|
| `updated_at` | `timestamp` | Timestamp of last update. | Not Null |
|
|
|
|
**Indexes**:
|
|
|
|
- `tenant_memberships_tenant_id_user_id_unique`: Unique constraint on `(tenant_id, user_id)` to ensure a user has only one role per tenant.
|
|
- `tenant_memberships_tenant_id_role_index`: Index on `(tenant_id, role)` for efficient role-based queries within a tenant.
|
|
- `tenant_memberships_user_id_index`: Index on `(user_id)` for efficiently finding all tenant memberships for a user.
|
|
|
|
## Relationships
|
|
|
|
- A `Tenant` has many `TenantMembership` records.
|
|
- A `User` has many `TenantMembership` records.
|
|
- A `TenantMembership` belongs to one `Tenant` and one `User`.
|