Ressourcenberechtigungen

Sowohl Einzelelementressourcen (z. B. Activity) als auch Sammelressourcen (z. B. Activities) können über einen Abschnitt permissions verfügen. In diesem Abschnitt werden die Aktionen definiert, die Benutzer für zugängliche Ressourcen ausführen können.

Der Abschnitt permissions besteht aus einer Liste von Berechtigungen, auf die jeweils ein boolescher Ausdruck folgt. Die Berechtigung wird nur dann gewährt, wenn der boolesche Ausdruck „true“ zurückgibt.

Der folgende Code definiert beispielsweise die Berechtigungen für die Ressource Claims (für eine Sammlung von Schadenfällen), wie sie in der Datei policyNumbers_core-1.0access.yaml deklariert ist. Die Berechtigung view wird immer gewährt. Die Berechtigung create wird gewährt, wenn der Gosu-Ausdruck user.hasPolicyAccess(resource, Optional.of(data)) „true“ zurückgibt.

Claims:
  permissions:

    view: true
    create: "user.hasPolicyAccess(resource, Optional.of(data))"

Berechtigungen für Elementressourcen

Für einzelne Elemente können Sie die Berechtigungen view, create, edit und delete angeben. Sie können auch Berechtigungen für benutzerdefinierte Geschäftsaktionen angeben. Wenn es beispielsweise einen POST-Endpunkt /activities/{activityId}/assign gibt, können Sie für eine Activity-Ressource eine Berechtigung assign angeben. Bei benutzerdefinierten Aktionen muss der Berechtigungsname mit dem am Ende des Endpunktpfads verwendeten Verb übereinstimmen.

Im Folgenden werden beispielsweise Berechtigungen für die Entität Claim angegeben. Beachten Sie, dass die Standardberechtigungen view und edit sowie die benutzerdefinierte Geschäftsaktionsberechtigung close angegeben werden.

Claim:
        permissions:
        view: "perm.Claim.view(resource.Claim)"
        edit: "perm.Claim.edit(resource.Claim)"
        ...
        close: "perm.Claim.close(resource.Claim)"
        ...

WARNUNG: Wenn Sie einen neuen Endpunkt erstellen, der eine benutzerdefinierte Aktion ausführt, dürfen Sie den Endpunkt nicht mit einem Namen benennen, der im Konflikt mit einer Basisberechtigung stehen würde, z. B. view, edit, create oder delete. Dies würde unerwartetes Berechtigungsverhalten zur Folge haben.

Wenn in einer Zugriffsdatei keine bestimmte Berechtigung angegeben ist, wird standardmäßig die Berechtigung des übergeordneten Elements der Ressource verwendet. Wenn eine bestimmte Ressource keinen Berechtigungsabschnitt aufweist, werden alle Berechtigungen standardmäßig auf die Berechtigung des übergeordneten Elements der Ressource gesetzt.

Mögliche boolesche Ausdrücke

Jeder Gosu-Ausdruck, der „true“ oder „false“ zurückgibt, kann als boolescher Ausdruck einer Berechtigung verwendet werden.

Für Berechtigungen umfasst die Basiskonfiguration die folgenden Arten von booleschen Ausdrücken:

Einen booleschen Wert
Das Schlüsselwort __inherit (in diesem Fall wird die Berechtigung vom übergeordneten Element der Ressource geerbt, z. B. ClaimActivities...view: __inherit)
Einen Gosu-Ausdruck einschließlich:
- Einen Perm-Ausdruck im Gosu-System (z. B. "perm.system.actview")
- Perm-Ausdrücke für eine Gosu-Ressource (z. B. "perm.Activity.view(resource.Activity)")
- Einen Gosu-Ausdruck (z. B. "!resource.Note.Confidential || resource.Note.Author == entity.User.util.CurrentUser || perm.Claim.viewvertraualnotes(resource.Note.Claim)")
- Eine Gosu-Methode, die auf der System-API-Ebene deklariert wird (z. B. "gw.rest.core.pl.util.v1.ActivityInternalPermissionUtil.canApprove(resource.Activity)")

Weitere Informationen zum Schreiben von Gosu-Ausdrücken, die nach System- oder Ressourcenberechtigungen suchen, finden Sie im Regelhandbuch.

In einigen Fällen sind mehrere Ausdrücke in mehreren Zeilen aufgeführt, wie im folgenden Beispiel. In diesem Fall werde die Ausdrücke mit AND verknüpft. Alle Ausdrücke müssen „true“ zurückgeben, damit die Berechtigung gewährt wird.

CheckSets:
  permissions:
    view:
      - __inherit
      - "perm.Claim.viewpayments(resource.Claim)"