Moritz
fecf98dc0e
Some checks reported errors
continuous-integration/drone/push Build was killed
CRITICAL FIX: Deny-filter was allowing all records instead of denying Fix: User validation in Member now uses actor from changeset.context
751 lines
37 KiB
Text
751 lines
37 KiB
Text
|
||
* ▐▛███▜▌ * Claude Code v2.0.76
|
||
* ▝▜█████▛▘ * Sonnet 4.5 · Claude Pro
|
||
* ▘▘ ▝▝ * /home/user/LIT/mitgliederverwaltung/mitgliederverwaltung
|
||
|
||
> führe git diff main aus, lese dir die roles-and-permissions docs durch und
|
||
erstelle ein code review vom aktuellen branch
|
||
|
||
● Ich führe die Aufgaben parallel aus:
|
||
|
||
● Bash(git diff main)
|
||
⎿ diff --git a/lib/mv/authorization/checks/has_permission.ex b/lib/mv/aut
|
||
horization/checks/has_permission.ex
|
||
new file mode 100644
|
||
… +656 lines (ctrl+o to expand)
|
||
|
||
|
||
● Search(pattern: "**/docs/**/roles*.md")
|
||
⎿ Found 3 files (ctrl+o to expand)
|
||
|
||
● Search(pattern: "**/docs/**/permission*.md")
|
||
⎿ Found 0 files
|
||
|
||
● Read(docs/roles-and-permissions-implementation-plan.md)
|
||
⎿ Read 1654 lines
|
||
|
||
● Read(docs/roles-and-permissions-architecture.md)
|
||
⎿ Read 2503 lines
|
||
|
||
● Read(docs/roles-and-permissions-overview.md)
|
||
⎿ Read 507 lines
|
||
|
||
● Ich habe den git diff und die Dokumentation gelesen. Jetzt erstelle ich das Code Review:
|
||
|
||
● Updated plan
|
||
⎿ /plan to preview
|
||
|
||
> /status
|
||
|
||
> /model
|
||
|
||
● Ich verifiziere noch die Member-Resource, um die Relationship-Frage zu klären:
|
||
|
||
● Search(pattern: "has_one :user|belongs_to :user|user_id", path:
|
||
"lib/mv/membership/member.ex", output_mode: "content")
|
||
⎿ Error searching files
|
||
|
||
● Search(pattern: "**/member.ex")
|
||
⎿ Found 1 file (ctrl+o to expand)
|
||
|
||
● Read(lib/membership/member.ex)
|
||
⎿ Read 1276 lines
|
||
|
||
● Die Member Resource hat tatsächlich has_one :user (Zeile 517). Die HasPermission Implementierung ist korrekt. Ich aktualisiere das Review:
|
||
|
||
● Updated plan
|
||
⎿ /plan to preview
|
||
|
||
● Updated plan
|
||
⎿ /plan to preview
|
||
|
||
● Ich habe das Code Review erstellt und verifiziert. Hier ist die Zusammenfassung:
|
||
|
||
Code Review: HasPermission Policy Check
|
||
|
||
Gesamtbewertung: Gut ✅
|
||
|
||
Positiv:
|
||
- Korrekte Ash.Policy.Check Implementierung mit strict_check/3 und auto_filter/3
|
||
- Umfassende Fehlerbehandlung (nil actor, nil role, invalid permission_set_name)
|
||
- Gute Test Coverage (~25 Tests)
|
||
- Die Relationship-Pfade sind korrekt - Member hat has_one :user (lib/membership/member.ex:517)
|
||
|
||
Kleinere Punkte:
|
||
- Dokumentation zwischen Moduledoc und Architecture Doc sollte vereinheitlicht werden
|
||
- Die Architektur-Dokumentation beschreibt user_id, die Implementierung nutzt user.id (funktional äquivalent, aber inkonsistent dokumentiert)
|
||
|
||
Merge-Empfehlung: ✅ Kann gemerged werden
|
||
|
||
---
|
||
Das vollständige Review befindet sich in /home/agent/.claude/plans/moonlit-soaring-coral.md.
|
||
⎿ User rejected Claude's plan:
|
||
╭─────────────────────────────────────────────────────────────────────────╮
|
||
│ Code Review: HasPermission Policy Check (Issue #6) │
|
||
│ │
|
||
│ Branch: feature/343_haspermission │
|
||
│ Base: main │
|
||
│ Reviewer: Claude Code │
|
||
│ │
|
||
│ --- │
|
||
│ Zusammenfassung │
|
||
│ │
|
||
│ Der Branch implementiert den HasPermission Policy Check (Issue #6 aus │
|
||
│ dem Implementation Plan). Dies ist eine zentrale Komponente des Rollen- │
|
||
│ und Berechtigungssystems, die Berechtigungen aus dem PermissionSets │
|
||
│ Modul ausliest und auf Ash Policies anwendet. │
|
||
│ │
|
||
│ Geänderte Dateien: │
|
||
│ - lib/mv/authorization/checks/has_permission.ex (neu, 239 Zeilen) │
|
||
│ - test/mv/authorization/checks/has_permission_test.exs (neu, 264 Zeilen)│
|
||
│ - test/mv/authorization/checks/has_permission_integration_test.exs (neu,│
|
||
│ 87 Zeilen) │
|
||
│ │
|
||
│ --- │
|
||
│ Positives │
|
||
│ │
|
||
│ 1. Saubere Architektur │
|
||
│ │
|
||
│ - Korrekte Implementierung von Ash.Policy.Check mit strict_check/3 und │
|
||
│ auto_filter/3 │
|
||
│ - Gute Separation of Concerns - Berechtigungslogik delegiert an │
|
||
│ PermissionSets Modul │
|
||
│ - Klare Modulstruktur mit Helper-Funktionen zur Reduktion von Nesting │
|
||
│ │
|
||
│ 2. Fehlerbehandlung │
|
||
│ │
|
||
│ - Umfassende Behandlung von Edge Cases (nil actor, nil role, invalid │
|
||
│ permission_set_name) │
|
||
│ - Graceful degradation - Fehler führen zu {:ok, false} statt Crashes │
|
||
│ - Debug-Logging für Autorisierungsfehler (lazy evaluation mit │
|
||
│ Logger.debug(fn -> ... end)) │
|
||
│ │
|
||
│ 3. Scope-Implementierung │
|
||
│ │
|
||
│ - Korrekte Implementierung aller drei Scopes: :all, :own, :linked │
|
||
│ - Wichtig: Die :linked Scope-Implementierung für CustomFieldValue │
|
||
│ traversiert korrekt die Relationship (member.user.id) │
|
||
│ - Die Filter-Expressions verwenden korrekt Ash.Expr │
|
||
│ │
|
||
│ 4. Test Coverage │
|
||
│ │
|
||
│ - Umfassende Unit Tests für alle Szenarien │
|
||
│ - Separate Integration Tests für Filter-Expression-Struktur │
|
||
│ - Tests für Error Handling und Logging │
|
||
│ │
|
||
│ --- │
|
||
│ Kritische Punkte │
|
||
│ │
|
||
│ 1. VERIFIZIERT: Relationship-Pfade in apply_scope/3 sind korrekt │
|
||
│ │
|
||
│ Die Implementierung verwendet: │
|
||
│ # Member (Zeile 191) │
|
||
│ {:filter, expr(user.id == ^actor.id)} │
|
||
│ │
|
||
│ # CustomFieldValue (Zeile 196) │
|
||
│ {:filter, expr(member.user.id == ^actor.id)} │
|
||
│ │
|
||
│ Verifiziert: Member hat has_one :user, Mv.Accounts.User │
|
||
│ (lib/membership/member.ex:517) │
|
||
│ │
|
||
│ Die Architektur-Dokumentation beschreibt member.user_id == actor.id, │
|
||
│ aber die Implementierung nutzt bewusst die Relationship user.id. Beides │
|
||
│ ist funktional äquivalent, da Ash die Relationship auflöst. │
|
||
│ │
|
||
│ HINWEIS: Der Commit db0a1870 ("fix: correct relationship filter paths") │
|
||
│ zeigt, dass dies eine bewusste Design-Entscheidung war, um Ash │
|
||
│ Relationship-Traversal zu nutzen statt direkter Foreign Key-Vergleiche. │
|
||
│ │
|
||
│ 2. Moduledoc entspricht nicht der Architektur-Dokumentation │
|
||
│ │
|
||
│ Der @moduledoc beschreibt die :linked Scope für Member als: │
|
||
│ - Member: member.user.id == actor.id (via has_one :user relationship) │
|
||
│ │
|
||
│ Die Architektur-Dokumentation sagt jedoch: │
|
||
│ - Member: member.user_id == actor.id (direct relationship) │
|
||
│ │
|
||
│ Empfehlung: Dokumentation vereinheitlichen. │
|
||
│ │
|
||
│ 3. FEHLER: match?/3 nicht implementiert │
|
||
│ │
|
||
│ Der Implementation Plan (Issue #6) spezifiziert: │
|
||
│ 4. Implement `match?/3` - the core authorization logic │
|
||
│ │
|
||
│ Die Implementierung verwendet stattdessen strict_check/3 und │
|
||
│ auto_filter/3. │
|
||
│ │
|
||
│ Bewertung: Dies ist kein Fehler - strict_check/3 und auto_filter/3 sind │
|
||
│ die korrekten Callbacks für Ash.Policy.Check. Die Dokumentation im │
|
||
│ Implementation Plan ist veraltet. Die Implementierung ist korrekt. │
|
||
│ │
|
||
│ 4. Error-Return-Typen │
|
||
│ │
|
||
│ Der Implementation Plan spezifiziert Error-Returns wie {:error, │
|
||
│ :no_actor}, aber die Implementierung gibt {:ok, false} zurück. │
|
||
│ │
|
||
│ Bewertung: Korrekt. Ash.Policy.Check erwartet {:ok, true | false | │
|
||
│ :unknown}, nicht {:error, ...}. Die Implementierung ist konform mit der │
|
||
│ Ash API. │
|
||
│ │
|
||
│ --- │
|
||
│ Verbesserungsvorschläge │
|
||
│ │
|
||
│ 1. Code: Fallback in apply_scope(:linked, ...) könnte problematisch sein│
|
||
│ │
|
||
│ # Zeile 199-200 │
|
||
│ _ -> │
|
||
│ {:filter, expr(user.id == ^actor.id or user_id == ^actor.id)} │
|
||
│ │
|
||
│ Dieser Fallback könnte zu unerwarteten Ergebnissen führen, wenn ein │
|
||
│ Resource weder user noch user_id hat. │
|
||
│ │
|
||
│ Empfehlung: Explizite Fehlerbehandlung statt Fallback oder Logging wenn │
|
||
│ der Fallback verwendet wird. │
|
||
│ │
|
||
│ 2. Tests: Integration Tests sind minimal │
|
||
│ │
|
||
│ Die Integration Tests (has_permission_integration_test.exs) testen nur │
|
||
│ die Struktur der Filter-Expressions, nicht deren Korrektheit in echten │
|
||
│ Queries. │
|
||
│ │
|
||
│ Empfehlung: Nach Implementierung der Resource Policies (Issues #7-#10) │
|
||
│ sollten End-to-End Tests hinzugefügt werden. │
|
||
│ │
|
||
│ 3. Tests: Fehlende Tests für describe/1 │
|
||
│ │
|
||
│ Der Test für describe/1 (Zeile 23-27) testet nur, dass ein String │
|
||
│ zurückgegeben wird, nicht den Inhalt. │
|
||
│ │
|
||
│ Minimal: Akzeptabel, da describe/1 nur für Logging/Debugging verwendet │
|
||
│ wird. │
|
||
│ │
|
||
│ 4. Performance: Logger.debug könnte optimiert werden │
|
||
│ │
|
||
│ Die Logging-Funktion log_auth_failure/4 erstellt einen String auch wenn │
|
||
│ Debug-Logging deaktiviert ist. │
|
||
│ │
|
||
│ Aktuell: Die Implementierung verwendet bereits lazy evaluation mit │
|
||
│ Logger.debug(fn -> ... end). Gut! │
|
||
│ │
|
||
│ --- │
|
||
│ Übereinstimmung mit Architektur-Dokumentation │
|
||
│ │
|
||
│ | Requirement | Status | Kommentar │
|
||
│ | │
|
||
│ |--------------------------------------------|--------|-----------------│
|
||
│ ----------------| │
|
||
│ | Implements Ash.Policy.Check | ✅ | Korrekt │
|
||
│ | │
|
||
│ | Reads actor.role.permission_set_name | ✅ | Korrekt │
|
||
│ | │
|
||
│ | Calls PermissionSets.get_permissions/1 | ✅ | Korrekt │
|
||
│ | │
|
||
│ | Applies scope :all | ✅ | Returns │
|
||
│ :authorized | │
|
||
│ | Applies scope :own | ✅ | Filter auf id ==│
|
||
│ ^actor.id | │
|
||
│ | Applies scope :linked for Member | ⚠️ | Verwendet │
|
||
│ user.id statt user_id | │
|
||
│ | Applies scope :linked for CustomFieldValue | ✅ | Traversiert │
|
||
│ korrekt | │
|
||
│ | Error handling graceful | ✅ | Keine Crashes │
|
||
│ | │
|
||
│ | Logging for failures | ✅ | Logger.debug mit│
|
||
│ lazy eval | │
|
||
│ │
|
||
│ --- │
|
||
│ Test Coverage Analyse │
|
||
│ │
|
||
│ | Test-Kategorie | Anzahl Tests | Bewertung | │
|
||
│ |--------------------------------|--------------|-------------| │
|
||
│ | Permission Lookup | 5 | ✅ Gut | │
|
||
│ | Scope :all | 2 | ✅ Gut | │
|
||
│ | Scope :own | 1 | ⚠️ Minimal | │
|
||
│ | Scope :linked | 2 | ⚠️ Minimal | │
|
||
│ | Error Handling | 7 | ✅ Sehr gut | │
|
||
│ | Logging | 2 | ✅ Gut | │
|
||
│ | Resource Name Extraction | 2 | ✅ Gut | │
|
||
│ | Integration (Filter Structure) | 4 | ✅ Gut | │
|
||
│ │
|
||
│ Gesamtbewertung Tests: ~25 Tests - entspricht den Erwartungen für Issue │
|
||
│ #6 │
|
||
│ │
|
||
│ --- │
|
||
│ Fazit │
|
||
│ │
|
||
│ Gesamtbewertung: Gut (mit Hinweisen) │
|
||
│ │
|
||
│ Die Implementierung ist solide und entspricht weitgehend den │
|
||
│ Anforderungen aus der Architektur-Dokumentation. Die wichtigsten Punkte:│
|
||
│ │
|
||
│ Positiv: │
|
||
│ - Korrekte Ash.Policy.Check Implementierung │
|
||
│ - Umfassende Fehlerbehandlung │
|
||
│ - Gute Test Coverage │
|
||
│ - Sauberer, lesbarer Code │
|
||
│ │
|
||
│ Zu Klären: │
|
||
│ 1. Relationship-Pfade (user.id vs user_id) - scheint bewusst so │
|
||
│ implementiert (siehe Commit-Message), sollte aber dokumentiert werden │
|
||
│ 2. Dokumentation zwischen Code und Architecture Doc vereinheitlichen │
|
||
│ │
|
||
│ Merge-Empfehlung: ✅ Kann gemerged werden, nachdem die Dokumentation │
|
||
│ aktualisiert wurde │
|
||
│ │
|
||
│ --- │
|
||
│ Checkliste für Merge │
|
||
│ │
|
||
│ - ~~Verify: Member hat has_one :user Relationship~~ → Bestätigt │
|
||
│ (lib/membership/member.ex:517) │
|
||
│ - Update: Moduledoc oder Architecture Doc für Konsistenz │
|
||
│ - Run: just test bestätigt alle Tests bestehen │
|
||
│ - Run: just lint zeigt keine Fehler │
|
||
│ │
|
||
│ │
|
||
│ │
|
||
│ │
|
||
│ │
|
||
│ │
|
||
│ │
|
||
│ │
|
||
│ │
|
||
│ │
|
||
│ │
|
||
│ │
|
||
│ │
|
||
│ │
|
||
│ │
|
||
│ │
|
||
╰─────────────────────────────────────────────────────────────────────────╯
|
||
|
||
> Erstelle einen sehr expliziten Plan in plan.md um den Member Resource
|
||
Policies Issue umzusetzen und gleichzeitig die Verbesserungen aus dem Review
|
||
zu übernehmen.
|
||
|
||
● Ich lese zuerst die relevanten Dateien, um einen präzisen Plan zu erstellen:
|
||
|
||
● Read(lib/mv/authorization/checks/has_permission.ex)
|
||
⎿ Read 240 lines
|
||
|
||
● Search(pattern: "policies do", path: "lib/membership/member.ex", output_mode:
|
||
"content")
|
||
⎿ Found 0 lines
|
||
|
||
● Read(lib/mv/authorization/permission_sets.ex)
|
||
⎿ Read 295 lines
|
||
|
||
● Jetzt erstelle ich den expliziten Implementation Plan:
|
||
|
||
● Updated plan
|
||
⎿ /plan to preview
|
||
⎿ You've hit your limit · resets 7pm (UTC)
|
||
/upgrade or /extra-usage to finish what you're working on.
|
||
|
||
> /model
|
||
⎿ Set model to sonnet (claude-sonnet-4-5-20250929)
|
||
|
||
> /plan
|
||
⎿ Current Plan
|
||
/home/agent/.claude/plans/moonlit-soaring-coral.md
|
||
|
||
# Implementation Plan: Member Resource Policies + Review-Verbesserungen
|
||
|
||
**Issue:** #7 (Member Resource Policies) + Code Review Verbesserungen
|
||
**Branch:** `feature/343_haspermission`
|
||
**Abhängigkeiten:** Issue #6 (HasPermission) ✅ bereits implementiert
|
||
|
||
---
|
||
|
||
## Übersicht
|
||
|
||
Dieser Plan implementiert:
|
||
1. **Member Resource Policies** gemäß Issue #7
|
||
2. **Dokumentations-Synchronisation** aus dem Code Review
|
||
3. **Fallback-Verbesserung** in HasPermission für robustere Fehlerbehandlung
|
||
|
||
---
|
||
|
||
## Teil 1: Member Resource Policies
|
||
|
||
### Datei: `lib/membership/member.ex`
|
||
|
||
**Position:** Nach `relationships do ... end` Block (ca. Zeile 528), VOR
|
||
`calculations do`
|
||
|
||
#### 1.1 Policies Block hinzufügen
|
||
|
||
```elixir
|
||
policies do
|
||
# =========================================================================
|
||
# Policy Order (WICHTIG!):
|
||
# 1. Special Case: User kann immer eigenes verknüpftes Mitglied
|
||
lesen/bearbeiten
|
||
# 2. General: HasPermission Check für alle anderen Fälle
|
||
# 3. Default: Forbid (implizit durch Ash wenn keine Policy matched)
|
||
# =========================================================================
|
||
|
||
# SPECIAL CASE: User kann sein verknüpftes Mitglied immer lesen/bearbeiten
|
||
# Diese Policy greift VOR dem HasPermission Check
|
||
# Verwendet Ash Relationship Traversal: user.id == actor.id
|
||
policy action_type([:read, :update]) do
|
||
description "Users can always access their linked member"
|
||
authorize_if expr(user.id == ^actor(:id))
|
||
end
|
||
|
||
# GENERAL: Alle anderen Operationen via HasPermission Check
|
||
# Delegiert an PermissionSets Modul für scope-basierte Autorisierung
|
||
policy action_type([:read, :create, :update, :destroy]) do
|
||
description "Check permissions from user's role via PermissionSets"
|
||
authorize_if Mv.Authorization.Checks.HasPermission
|
||
end
|
||
end
|
||
```
|
||
|
||
#### 1.2 Actor-Preparation für Role-Loading
|
||
|
||
**Position:** Nach `policies do ... end` Block
|
||
|
||
```elixir
|
||
# Ensure actor has role preloaded for policy checks
|
||
preparations do
|
||
prepare build(actor_context: [role: [:permission_set_name]])
|
||
end
|
||
```
|
||
|
||
**ALTERNATIV** (falls Ash 3.0 andere Syntax benötigt):
|
||
Die Role muss im Actor bereits geladen sein. Prüfen ob `Mv.Accounts.User`
|
||
bereits `:role` preloaded.
|
||
|
||
---
|
||
|
||
## Teil 2: Dokumentations-Synchronisation
|
||
|
||
### 2.1 Datei: `lib/mv/authorization/checks/has_permission.ex`
|
||
|
||
**Zeile 23-25:** Moduledoc aktualisieren für Konsistenz mit Code
|
||
|
||
```elixir
|
||
# VORHER:
|
||
# - Member: member.user.id == actor.id (via has_one :user relationship)
|
||
# - CustomFieldValue: custom_field_value.member.user.id == actor.id (traverses
|
||
member → user relationship!)
|
||
|
||
# NACHHER (konsistent mit tatsächlichem Code):
|
||
## Scope Behavior
|
||
|
||
- **:all** - Authorizes without filtering (returns all records)
|
||
- **:own** - Filters to records where record.id == actor.id
|
||
- **:linked** - Filters based on resource type using Ash relationship traversal:
|
||
- Member: `user.id == actor.id` (traverses has_one :user relationship)
|
||
- CustomFieldValue: `member.user.id == actor.id` (traverses belongs_to :member
|
||
→ has_one :user)
|
||
- Other resources: Falls back to `user.id == actor.id or user_id == actor.id`
|
||
```
|
||
|
||
### 2.2 Datei: `docs/roles-and-permissions-architecture.md`
|
||
|
||
**Zeilen 799-812:** apply_scope Dokumentation aktualisieren
|
||
|
||
```markdown
|
||
# VORHER:
|
||
# - Member: member.user_id == actor.id
|
||
# - CustomFieldValue: custom_field_value.member.user_id == actor.id
|
||
|
||
# NACHHER (konsistent mit Implementation):
|
||
- Member: `user.id == actor.id` (uses Ash relationship traversal)
|
||
- CustomFieldValue: `member.user.id == actor.id` (traverses relationships)
|
||
```
|
||
|
||
---
|
||
|
||
## Teil 3: Fallback-Verbesserung in HasPermission
|
||
|
||
### Datei: `lib/mv/authorization/checks/has_permission.ex`
|
||
|
||
**Zeilen 205-208:** Fallback expliziter machen
|
||
|
||
```elixir
|
||
# VORHER:
|
||
_ ->
|
||
# Fallback for other resources: try user relationship first, then user_id
|
||
{:filter, expr(user.id == ^actor.id or user_id == ^actor.id)}
|
||
|
||
# NACHHER (mit Logging):
|
||
_ ->
|
||
# Fallback for other resources: try user relationship first, then user_id
|
||
# This fallback is intentionally permissive - logs warning for investigation
|
||
Logger.warning(fn ->
|
||
"HasPermission using fallback :linked filter for resource: #{resource_name}.
|
||
" <>
|
||
"Consider adding explicit case for this resource."
|
||
end)
|
||
{:filter, expr(user.id == ^actor.id or user_id == ^actor.id)}
|
||
```
|
||
|
||
---
|
||
|
||
## Teil 4: Tests für Member Policies
|
||
|
||
### Neue Datei: `test/membership/member_policies_test.exs`
|
||
|
||
```elixir
|
||
defmodule Mv.Membership.MemberPoliciesTest do
|
||
@moduledoc """
|
||
Tests for Member resource policies.
|
||
|
||
Verifies that:
|
||
- Special case: Users can access linked member
|
||
- HasPermission scopes work correctly for each permission set
|
||
"""
|
||
use Mv.DataCase, async: true
|
||
|
||
alias Mv.Membership
|
||
alias Mv.Accounts
|
||
|
||
# Test Fixtures
|
||
defp create_user_with_role(permission_set_name) do
|
||
# Create role
|
||
{:ok, role} = Mv.Authorization.create_role(%{
|
||
name: "Test Role #{System.unique_integer()}",
|
||
permission_set_name: permission_set_name
|
||
})
|
||
|
||
# Create user with role
|
||
{:ok, user} = Accounts.create_user(%{
|
||
email: "test-#{System.unique_integer()}@example.com",
|
||
password: "password123!",
|
||
role_id: role.id
|
||
})
|
||
|
||
# Preload role
|
||
Ash.load!(user, :role)
|
||
end
|
||
|
||
defp create_member_linked_to(user) do
|
||
{:ok, member} = Membership.create_member(%{
|
||
email: user.email,
|
||
user: %{id: user.id}
|
||
})
|
||
member
|
||
end
|
||
|
||
defp create_unlinked_member do
|
||
{:ok, member} = Membership.create_member(%{
|
||
email: "unlinked-#{System.unique_integer()}@example.com"
|
||
})
|
||
member
|
||
end
|
||
|
||
describe "Special Case: Linked Member Access" do
|
||
test "user can read their linked member regardless of role" do
|
||
user = create_user_with_role("own_data")
|
||
member = create_member_linked_to(user)
|
||
|
||
result = Membership.get_member(member.id, actor: user)
|
||
|
||
assert {:ok, returned_member} = result
|
||
assert returned_member.id == member.id
|
||
end
|
||
|
||
test "user can update their linked member regardless of role" do
|
||
user = create_user_with_role("own_data")
|
||
member = create_member_linked_to(user)
|
||
|
||
result = Membership.update_member(member, %{notes: "Updated"}, actor:
|
||
user)
|
||
|
||
assert {:ok, updated_member} = result
|
||
assert updated_member.notes == "Updated"
|
||
end
|
||
end
|
||
|
||
describe "own_data permission set (Mitglied)" do
|
||
test "cannot read unlinked member" do
|
||
user = create_user_with_role("own_data")
|
||
_linked_member = create_member_linked_to(user)
|
||
unlinked_member = create_unlinked_member()
|
||
|
||
result = Membership.get_member(unlinked_member.id, actor: user)
|
||
|
||
# Should return not found or forbidden
|
||
assert {:error, _} = result
|
||
end
|
||
|
||
test "cannot create member" do
|
||
user = create_user_with_role("own_data")
|
||
|
||
result = Membership.create_member(%{
|
||
email: "new@example.com"
|
||
}, actor: user)
|
||
|
||
assert {:error, %Ash.Error.Forbidden{}} = result
|
||
end
|
||
end
|
||
|
||
describe "read_only permission set (Vorstand)" do
|
||
test "can read all members" do
|
||
user = create_user_with_role("read_only")
|
||
_member1 = create_unlinked_member()
|
||
_member2 = create_unlinked_member()
|
||
|
||
result = Membership.list_members(actor: user)
|
||
|
||
assert {:ok, members} = result
|
||
assert length(members) >= 2
|
||
end
|
||
|
||
test "cannot create member" do
|
||
user = create_user_with_role("read_only")
|
||
|
||
result = Membership.create_member(%{
|
||
email: "new@example.com"
|
||
}, actor: user)
|
||
|
||
assert {:error, %Ash.Error.Forbidden{}} = result
|
||
end
|
||
|
||
test "cannot update member" do
|
||
user = create_user_with_role("read_only")
|
||
member = create_unlinked_member()
|
||
|
||
result = Membership.update_member(member, %{notes: "Updated"}, actor:
|
||
user)
|
||
|
||
assert {:error, %Ash.Error.Forbidden{}} = result
|
||
end
|
||
end
|
||
|
||
describe "normal_user permission set (Kassenwart)" do
|
||
test "can read all members" do
|
||
user = create_user_with_role("normal_user")
|
||
_member = create_unlinked_member()
|
||
|
||
result = Membership.list_members(actor: user)
|
||
|
||
assert {:ok, _members} = result
|
||
end
|
||
|
||
test "can create member" do
|
||
user = create_user_with_role("normal_user")
|
||
|
||
result = Membership.create_member(%{
|
||
email: "new-#{System.unique_integer()}@example.com"
|
||
}, actor: user)
|
||
|
||
assert {:ok, _member} = result
|
||
end
|
||
|
||
test "can update any member" do
|
||
user = create_user_with_role("normal_user")
|
||
member = create_unlinked_member()
|
||
|
||
result = Membership.update_member(member, %{notes: "Updated"}, actor:
|
||
user)
|
||
|
||
assert {:ok, updated} = result
|
||
assert updated.notes == "Updated"
|
||
end
|
||
|
||
test "cannot destroy member" do
|
||
user = create_user_with_role("normal_user")
|
||
member = create_unlinked_member()
|
||
|
||
result = Membership.destroy_member(member, actor: user)
|
||
|
||
assert {:error, %Ash.Error.Forbidden{}} = result
|
||
end
|
||
end
|
||
|
||
describe "admin permission set" do
|
||
test "can perform all CRUD operations" do
|
||
user = create_user_with_role("admin")
|
||
|
||
# Create
|
||
{:ok, member} = Membership.create_member(%{
|
||
email: "admin-test-#{System.unique_integer()}@example.com"
|
||
}, actor: user)
|
||
|
||
# Read
|
||
{:ok, _} = Membership.get_member(member.id, actor: user)
|
||
|
||
# Update
|
||
{:ok, _} = Membership.update_member(member, %{notes: "Admin"}, actor:
|
||
user)
|
||
|
||
# Destroy
|
||
{:ok, _} = Membership.destroy_member(member, actor: user)
|
||
end
|
||
end
|
||
end
|
||
```
|
||
|
||
---
|
||
|
||
## Ausführungsreihenfolge
|
||
|
||
### Schritt 1: HasPermission Verbesserungen (5 min)
|
||
1. Öffne `lib/mv/authorization/checks/has_permission.ex`
|
||
2. Update Moduledoc (Zeilen 19-26)
|
||
3. Add Logging zum Fallback (Zeilen 205-208)
|
||
|
||
### Schritt 2: Member Policies hinzufügen (10 min)
|
||
1. Öffne `lib/membership/member.ex`
|
||
2. Finde Position nach `relationships do ... end` (ca. Zeile 528)
|
||
3. Füge `policies do ... end` Block ein
|
||
4. Optional: Prüfe ob actor preparation nötig
|
||
|
||
### Schritt 3: Dokumentation aktualisieren (5 min)
|
||
1. Update `docs/roles-and-permissions-architecture.md` Zeilen 799-812
|
||
|
||
### Schritt 4: Tests schreiben (15 min)
|
||
1. Erstelle `test/membership/member_policies_test.exs`
|
||
2. Implementiere Test-Fixtures
|
||
3. Schreibe Tests für alle Permission Sets
|
||
|
||
### Schritt 5: Validierung (5 min)
|
||
1. `just test test/membership/member_policies_test.exs`
|
||
2. `just test test/mv/authorization/` (bestehende Tests)
|
||
3. `just lint`
|
||
|
||
---
|
||
|
||
## Dateien die geändert werden
|
||
|
||
| Datei | Änderung |
|
||
|-------|----------|
|
||
| `lib/membership/member.ex` | `policies do` Block hinzufügen (~15 Zeilen) |
|
||
| `lib/mv/authorization/checks/has_permission.ex` | Moduledoc + Fallback-Logging
|
||
(~10 Zeilen) |
|
||
| `docs/roles-and-permissions-architecture.md` | Scope-Dokumentation
|
||
aktualisieren (~5 Zeilen) |
|
||
| `test/membership/member_policies_test.exs` | Neue Datei (~150 Zeilen) |
|
||
|
||
---
|
||
|
||
## Risiken und Mitigationen
|
||
|
||
| Risiko | Mitigation |
|
||
|--------|------------|
|
||
| Policy-Order falsch | Special Case MUSS vor General stehen |
|
||
| Actor ohne Role | HasPermission handhabt das bereits graceful |
|
||
| Bestehende Tests brechen | Tests mit `actor: user` Parameter aktualisieren |
|
||
| Performance | Minimal - Policies werden nur bei Queries evaluiert |
|
||
|
||
---
|
||
|
||
## Akzeptanzkriterien (aus Issue #7)
|
||
|
||
- [x] Policies block added to Member resource
|
||
- [ ] All CRUD actions protected by HasPermission
|
||
- [ ] Special case: User can always access linked member
|
||
- [ ] Policy order is correct (specific before general)
|
||
- [ ] Actor preloads :role relationship
|
||
- [ ] All policies tested
|
||
|
||
|
||
|
||
> /status
|
||
⎿ Status dialog dismissed
|
||
|
||
|
||
|