Worum es geht
Stell dir eine Gehaltsabrechnung payslip vor. Viele Personen dürfen sie lesen: Name, Monat, Abteilung. Das Feld salary sollen aber nur wenige sehen und noch weniger ändern.
Dafür legst du am einfachen Feld salary eine Rolle fest, z. B. payslip-salary-read. Ein einfaches Feld ist ein Feld mit einem Wert (Text, Zahl, Datum), keine Beziehung zu einem anderen Modell.
An einer Beziehung ist das anders: Dort öffnet eine Feldrolle einen zusätzlichen Weg zum anderen Modell. Siehe Rechte auf Beziehungen (Feldrollen).
Ein Datensatz, zwei Sichten
flowchart LR
A(["Person mit payslip-read"]) -->|"response: +"| R1["employeeName: Anna<br/>salary: –"]
B(["Person mit payslip-read<br/>und payslip-salary-read"]) -->|"response: +"| R2["employeeName: Anna<br/>salary: 5000"]
Beide lesen denselben Datensatz. Die erste Person bekommt salary nicht zu sehen, die zweite schon.
Welche Rolle wofür
Eine Rolle wirkt nur für die Operation, für die sie festgelegt ist. Legst du für eine Operation keine Rolle fest, reicht dort die Rolle des Modells.
| Was die Anfrage tut | Rolle am Feld |
|---|---|
| Feld lesen, danach filtern oder sortieren | …-read |
| beim Anlegen einen Wert setzen | …-create |
| einen vorhandenen Wert ändern (PUT oder PATCH) | …-update |
einen Wert leeren (auf null setzen) | …-delete, oder …-update, wenn am Feld keine Löschrolle festgelegt ist |
Die Namen bildet der Generator wie bei allen Feldrollen: Basisrolle, Feldname, Operation. Siehe Wie Rollennamen entstehen.
Lesen
| Person hat payslip-salary-read | Wie die response das Feld anfordert | Ergebnis |
|---|---|---|
| ja | – | Feld mit Wert |
| nein | über + oder * | Feld fehlt (null), Rest der Antwort normal |
| nein | beim Namen, z. B. "salary" | 403 missing-permission|payslip-salary-read |
Warum zwei Antworten? + bedeutet „alle einfachen Felder, die ich sehen darf“. Nennst du das Feld beim Namen, willst du genau diesen Wert. Ein leerer Wert wäre dann nicht von „nicht gesetzt“ zu unterscheiden, deshalb lehnt CDMS ab.
Das Feld fehlt überall, wo der Datensatz herauskommt:
- beim Lesen und bei jeder Zeile einer Suche
- in der Antwort auf Anlegen, PUT und PATCH (sie ist ein Lesevorgang)
- wenn du das Modell über eine Beziehung eines anderen Modells liest
- in jeder Version der Änderungshistorie
- in jeder Zeile einer Suche auf einem abstrakten Modell
Schreiben
CDMS prüft beim Schreiben die Änderung, nicht die bloße Nennung des Felds.
| Wert in der Anfrage | Rolle vorhanden | Ergebnis |
|---|---|---|
| gleich dem gespeicherten Wert | – | erlaubt, es ändert sich nichts |
| anderer Wert | …-update (beim Anlegen …-create) | wird gespeichert |
| anderer Wert | nein | 403 missing-permission|payslip-salary-update, nichts gespeichert |
PATCH mit null | …-delete | Feld wird geleert |
PATCH mit null | nein | 403 missing-permission|payslip-salary-delete |
| PUT ohne Wert | …-delete | Feld wird geleert |
| PUT ohne Wert | nein | gespeicherter Wert bleibt, kein Fehler |
Werte, die ein Defaultwert oder ein Hook setzt, prüft CDMS nicht. Sie kommen vom Server, nicht von der Person.
Suchen
Ein Filter nach einem Wert verrät ihn, Schritt für Schritt: „Ist das Gehalt größer als 4000? Größer als 5000?“ Auch eine Sortierung verrät ihn über die Reihenfolge. Deshalb gilt:
- Ein Filter auf ein Feld, das du nicht lesen darfst, ergibt 403 mit der Leserolle des Felds. Das gilt auch in verschachtelten Gruppen.
- Eine Sortierung danach ergibt ebenfalls 403.
- Ein Pfad wie
vault.codewird bis zum letzten Feld verfolgt. Trägtcodeeine Leserolle, brauchst du sie für den Filter. - Bei einem abstrakten Modell zählt das Feld jedes Untertyps.
Siehe auch Kaputte Filter.
Varianten
Wann: POST /payslip/read/{id}, response: ["+"], nur payslip-read
-
1CDMSprüft die Leserolle von
payslipund liest den Datensatz -
2CDMS
payslip-salary-readfehlt → lässtsalaryweg
Ergebnis: 200, salary ist null.
Wann: POST /payslip/create mit salary, ohne payslip-salary-create
-
1CDMSprüft die Anlegerolle von
payslip -
2CDMS
salaryhat einen Wert,payslip-salary-createfehlt
Ergebnis: 403, es wird nichts angelegt. Ohne salary im Körper geht das Anlegen durch.
Wann: gelesen ohne payslip-salary-read, geändert, per PUT zurück
-
1CDMS
salaryfehlt im Körper,payslip-salary-deletefehlt -
2CDMSlässt den gespeicherten Wert stehen und schreibt die anderen Felder
Ergebnis: 200, das Gehalt ist unverändert.
Wann: POST /payslip/query mit Filter salary AFTER 4500, ohne payslip-salary-read
-
1CDMSprüft jeden Filter und jede Sortierung gegen die Leserollen der Felder
Ergebnis: 403 missing-permission|payslip-salary-read, bevor gesucht wird.
Fallen
Wie es weitergeht
- Rollen auf Beziehungen: Rechte auf Beziehungen (Feldrollen)
- Die Ebenen im Zusammenhang: Die drei Ebenen im Überblick
- Welche Felder eine Antwort enthält: Feldauswahl