Arten und Aktionen¶

Diese Seite ist zum Nachschlagen: wie eine Regel aussieht, welche Arten von Dingen eine Regel nennen kann und was jede Aktion auf jeder Art bedeutet. Was Regeln und Rollen sind, steht unter Rollen und Zugriff.

Eine Regel¶

{"id": "own-department", "effect": "permit", "kind": "membership",
 "actions": ["see", "write"],
 "match": {"labels": {"office": "utrecht"}},
 "when": [{"atom": "label_among", "label": "department", "attribute": "department"}]}

Eine Bedingung in when ist eine von dreien:

Die Attribute, die eine Bedingung lesen kann, sind role (der Name einer eingebauten Rolle oder die ID rol_... einer eigenen Rolle), group (die ID grp_... einer Gruppe) und jedes Attribut, das die Organisation oder eine Organisation darüber festgelegt hat. Eine Bedingung auf ein anderes Attribut lehnt OS ab.

Wie OS entscheidet¶

• Nichts ist erlaubt ohne ein passendes permit; ein passendes forbid lehnt immer ab. Die Reihenfolge spielt keine Rolle.
• Eine Regel passt, wenn ihr ganzes match für das Ding und ihr ganzes when für die Person zutrifft. Es gibt kein „oder“ und kein „nicht“: Zwei mögliche Werte sind zwei Regeln.
• Labels und Attribute sind Mengen von Werten. Ein Ding ohne das Label passt auf keinen Test dieses Labels.
• Keine Aktion schließt eine andere ein. OS fragt zuerst see; was die Person nicht sehen darf, existiert für sie nicht (404).
• Etwas anlegen ist ein write, entschieden anhand der Labels in der Anfrage. Beim Ändern von Labels wird anhand der alten und der neuen Labels entschieden.

Grenzen und Einschränkungen¶

Außerdem lehnt OS ab:

• ein forbid über organisation, membership, invitation, group, role, rule oder attribute: Für die Verwaltung schreiben Sie nur, was erlaubt ist;
• eine Regel über placement außerhalb der obersten Organisation;
• ein attribute_has mit einem Wert außerhalb der festen Liste des Attributs, auch wenn eine Organisation darüber es festlegte;
• eine Bedingung auf ein Attribut, das niemand festgelegt hat;
• eine Regel über eine Art von OS mit einer Aktion, die die Art nicht kennt: Jede Art nimmt nur die Aktionen, die in ihrer Zeile stehen, sodass zum Beispiel use auf group oder membership nicht möglich ist;
• eine Regel über die KI-Funktionen mit einem Teil, den die Art nicht nimmt (unten);
• in einer eigenen Rolle: eine Regel über router, egress_host, artifact_download, share_link oder memory_write.

Jede dieser Ablehnungen ist ein 422 beim Schreiben; es ändert sich nichts.

Eine Regel, die erlaubt, was nicht im Dienst der Organisation ist, lehnt OS mit 403 ab (This is not part of your organisation's service.): in einer eigenen Rolle, im Regeldokument und wenn Sie eine eigene Rolle oder eine Gruppe mit einer solchen Rolle vergeben. Eine eingebaute Rolle vergeben Sie immer; der Dienst macht sie nur kleiner.

Im Dienst¶

Ein Plan oder eine Ausnahme nennt Arten mit ihren Aktionen, wie eine Regel, aber ohne match und when. Diese Arten sind in jedem Dienst und in keinem Plan: organisation, membership, invitation, group, role, rule, attribute, audit_event, service, webhook, event, export und notification_channel, und außerdem placement und service_plan, die nur Artific verwaltet. Einen Plan oder eine Ausnahme, die eine dieser Arten nennt, lehnt OS mit 422 ab. Jede andere Art ist nur im Dienst, wenn ein Plan oder eine Ausnahme sie gibt, ebenso wie die Arten der Anmeldung Ihres Unternehmens, domain und sign_in.

Ein Bestandteil nennt nur Aktionen, die die Art kennt: bei den Arten von OS die in ihrer Zeile, bei denen der KI-Funktionen die in ihrer Tabelle. So nimmt thread kein use. Die Arten ohne Aktionen (router, egress_host, artifact_download, share_link, memory_write) sind ganz im Dienst oder nicht: Ein Bestandteil dazu nennt keine actions. Sonst lehnt OS den Plan oder die Ausnahme mit 422 ab.

Die Arten von OS¶

Eine Art nimmt nur die Aktionen, die in ihrer Zeile stehen: service nur see und write, und organisation, membership, invitation, group, domain und sign_in kein use. Eine Regel, einen Plan oder eine Ausnahme, die eine andere Aktion nennt, lehnt OS mit 422 ab. Eine Regel ohne actions gilt für die Aktionen, die die Art kennt, und allowed_actions nennt nie eine andere.

placement und service_plan entscheidet OS nur für den, der aus der obersten Organisation handelt. Ein write auf service entscheidet OS in der Organisation darüber, für den, der dort org-admin mit Reichweite descendants hat (wie).

Was match bei einem Ding von OS liest:

Die Arten der KI-Funktionen¶

Diese Arten betreffen, was Mitglieder in den KI-Funktionen tun. Sie stehen in CoreAccessKind.

Eine Art ohne Aktionen kennt keine actions: Die Regel betrifft die Art als Ganzes.

Nicht jede Art nimmt jeden Teil einer Regel. Eine Regel mit einem Teil, den die Art nicht nimmt, oder mit einer Aktion, die sie nicht kennt, lehnt OS mit 422 ab, wenn Sie sie schreiben:

• Zeilen (thread, memory_record, knowledge_source, stored_file, datastore_record) haben keinen Namen, also kein match.names. Das Label subject ist, wer die Zeile angelegt hat; ein leeres subject ("") ist eine gemeinsame Zeile. Bei den KI-Funktionen lesen Sie das Label subject nur auf Zeilen.
• file und datastore tragen keine Labels, also kein match.labels, und als Bedingung nur attribute_has.
• Für die ganze Organisation (router, egress_host, artifact_download, share_link, memory_write): keine Bedingung an die Person (when), und deshalb nur im Regeldokument, nie in einer Rolle (wie). Sie nehmen keine Labels; egress_host nimmt match.names für die Adressen. Modell-Router und Downloads erreichen standardmäßig jedes Mitglied; Gedächtnis schreiben und Teilen über einen Link niemanden, bis das Regeldokument sie erlaubt.