Worum es geht
Zwei Personen schicken dieselbe Suche und bekommen verschiedene Treffer. Das ist kein Fehler: CDMS nimmt zu jeder Suche Filter dazu, die der Client nicht sieht und nicht abschalten kann.
Der Baum hinter jeder Suche
flowchart TB
W["AND – Wurzel von CDMS"] --> C["dein query"]
W --> O["eigene Daten<br/>_userId = angemeldete Person"]
W --> A["Attributfilter<br/>z. B. companyId IN (Firmen aus dem Profil)"]
W --> P["eigene Pflichtfilter<br/>des Projekts"]
DB[("Datenbank des Mandanten")] -.->|"bei MULTI: Mandant wirkt über die Wahl der Datenbank"| W
| Filter | Wann er mitläuft | Wirkung |
|---|---|---|
| Eigene Daten (Owner-Filter) | bei Modellen, deren Objekte einer Person gehören | nur Objekte, deren _userId die angemeldete Person ist |
| Attributfilter | wenn das Modell einen Attributfilter hat | nur Objekte, deren Feld zu einem Attribut im Profil passt |
| Eigene Pflichtfilter | wenn das Projekt einen Filter für das Modell registriert | was der Filter des Projekts vorgibt |
| Mandant | wenn jeder Mandant eine eigene Datenbank hat (Betriebsart MULTI) | kein Filter in der Abfrage: CDMS liest gleich aus der Datenbank des Mandanten, siehe SINGLE und MULTI |
Details: Nur die eigenen Daten, Attributfilter, Eigene Filter.
Der Attributfilter im Einzelnen
Ein Attributfilter verbindet ein Attribut im Profil der Person mit einem Feld im Modell. Beispiel: Das Profil hat company: ["123456", "654321"], das Modell order hat das Feld companyId.
| Attribut company im Profil | Filter auf companyId |
|---|---|
| "123456" | companyId = 123456 |
| "123456", "654321" oder "123456,654321" | companyId IN (123456, 654321) |
| enthält "*" | kein Filter, alle Aufträge |
| fehlt | 422 missing-attribute-on-profile|company |
| vorhanden, aber leer | 422 empty-attribute-on-profile|company |
Ein fehlendes oder leeres Attribut heißt nie „alles sehen“. Die Anfrage scheitert, statt alle Daten zu liefern.
Überall dieselben Filter
Die Sicherheitsfilter gelten nicht nur für POST /query:
Wann: POST /query
Die Treffer und totalCount enthalten nur, was die Filter durchlassen.
Ergebnis: Zwei Personen, zwei verschiedene Listen.
Wann: POST /read/{id}
Ein Objekt, das die Filter ausschließen, gibt es für die Person nicht.
Ergebnis: 404, siehe Warum Unsichtbares 404 liefert.
Wann: ausgebaute Liste, z. B. { "field": "orders" }
Auch die Einträge einer Liste laufen durch die Filter ihres Modells.
Ergebnis: Nur die sichtbaren Einträge.
Wann: PUT, PATCH, DELETE
CDMS prüft vorher mit denselben Filtern, ob das Objekt sichtbar ist.
Ergebnis: Was du nicht lesen darfst, kannst du auch nicht ändern: 404.
Wenn ein Pflichtfilter nicht anwendbar ist
Kein Filter fällt still weg: Ohne ihn würde die Suche mehr Zeilen liefern als gewollt, bei einem Sicherheitsfilter sogar alle. Einen Filter vom Client, der nicht passt, lehnt CDMS deshalb ab (siehe Wenn ein Filter nicht passt). Sicherheitsfilter sind Pflichtfilter, und bei ihnen liegt der Fehler nie beim Client:
- Feld unbekannt oder Operator passt nicht → Anfrage abgelehnt
- 400
unknown-search-key|…,unsupported-operator|… - der Client korrigiert seine Anfrage
- Feld unbekannt oder Operator passt nicht → Suche scheitert
- 500
unresolvable-mandatory-filter|<feld>|… - lieber kein Ergebnis als zu viel
Ein solcher Fehler ist ein Konfigurationsfehler im Projekt, etwa ein Attributfilter auf ein Feld, das es im Modell nicht gibt.