local-it/mitgliederverwaltung
local-it/mitgliederverwaltung
2
3
Fork 0
Code Issues 57 Pull requests 3 Projects 2 Releases 5 Packages 1 Activity Actions
mitgliederverwaltung/docs/roles-and-permissions-implementation-plan.md

2.2 KiB
Raw Permalink Blame History

Roles and Permissions - Implementation Record (MVP)

Status: ✅ Implemented (2026-01-08, PR #346, closes #345) Related: Overview · Architecture

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 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.