39 lines
2.2 KiB
Markdown
39 lines
2.2 KiB
Markdown
# Roles and Permissions - Implementation Record (MVP)
|
||
|
||
**Status:** ✅ Implemented (2026-01-08, PR #346, closes #345)
|
||
**Related:** [Overview](./roles-and-permissions-overview.md) · [Architecture](./roles-and-permissions-architecture.md)
|
||
|
||
> Historical record of how the MVP (Phase 1) of the hardcoded Roles & Permissions
|
||
> system was built. The architecture document is the canonical design reference;
|
||
> the DB migration/rollback steps and the "What's NOT in MVP" boundary now live in
|
||
> its [Migration Strategy](./roles-and-permissions-architecture.md#migration-strategy)
|
||
> section.
|
||
|
||
## How the MVP was built
|
||
|
||
The MVP shipped as **PR #346 (closes #345)** across four week-sized sprints, built
|
||
test-first (TDD) with the work split into 15 issues:
|
||
|
||
- **Sprint 1 — Foundation:** `Role` Ash resource + `users.role_id` FK (#1); hardcoded
|
||
`PermissionSets` module with the 4 sets `own_data`/`read_only`/`normal_user`/`admin` (#2);
|
||
Role CRUD admin LiveViews (#3).
|
||
- **Sprint 2 — Policies:** `HasPermission` custom Ash policy check (#6); resource policies
|
||
for Member (#7), User (#8), CustomFieldValue (#9), CustomField (#10); page-permission
|
||
router plug (#11). Issues #7–#11 ran in parallel after #6.
|
||
- **Sprint 3 — Special cases & seeds:** linked-member email validation (#12); role seed
|
||
data + default-role assignment (#13).
|
||
- **Sprint 4 — UI & integration:** `MvWeb.Authorization` UI helper (`can?/3`,
|
||
`can_access_page?/2`) (#14); admin role-management UI (#15); applying UI authorization
|
||
to existing LiveViews + navbar (#16); per-role integration journey tests (#17).
|
||
|
||
The 5 seeded roles map to permission sets as: Mitglied → own_data (system role),
|
||
Vorstand → read_only, Kassenwart → normal_user, Buchhaltung → read_only, Admin → admin.
|
||
|
||
Issues #4, #5, #18 (DB-backed permission tables and ETS cache) were intentionally
|
||
**not** built — see "What's NOT in MVP" in the architecture document.
|
||
|
||
## Scope, migration & rollback
|
||
|
||
For the MVP scope boundary, the DB migration (create `roles`, add `users.role_id`),
|
||
the seed step, and the two-tier rollback plan (`mix ecto.rollback` → code revert), see
|
||
[Architecture › Migration Strategy](./roles-and-permissions-architecture.md#migration-strategy).
|