Berechtigungen von Packageobjekten

Allgemein

Alle Objekte, die in der be_package.yaml unter objects definiert werden, können mit Rollen-Berechtigungen versehen werden. Ausgenommen davon sind Elemente, die nur propagierte Berechtigungen empfangen (z.B. commands propagieren an menus, für menus können somit keine eigenen Berechtigungen hinterlegt werden).

Entitäten

Bei einer Entität können einzelne CRUD-Berechtigungen gepflegt werden. Ein CRUD-Berechtigung basiert immer auf einer Rolle und kann optional Bedingungen beinhalten. In einem Recht kann zu der Rolle immer nur eine Bedingung gepflegt werden.

Bei einem update oder einem delete muss der User auf dem Datensatz auch Leserechte haben.

Wenn keine Bedingung angegeben wird, ist die Rolle für alle Datensätze berechtigt.

Wenn ein Nutzer mehrere Rollen hat, ist er für alle Datensätze berechtigt, zu denen ihn eine seiner Rollen berechtigt. Also für die Vereinigungsmenge aller Datensätze zu denen die jeweiligen Rollen berechtigt sind.

Beispiele

Um die Codebeispiele kurz zu halten, beziehen sich alle hierauf folgenden Ausschnitte jeweils nur auf das permissions Objekt in Zeile 8. Der Rest der Entität bleibt in jedem Beispiel gleich.

packageKey: LIEFPORT
objects:
  entities:
  - entityName: LIEFPORT_Auftraege
    fields: [...]
    primaryKeyName: ID
    label: Test-Entität
    permissions:
      read: ...
      create: ...
      update: ...
      delete ...

Read Filter

In folgendem Beispiel werden die Leseberechtigungen von Rolle A und Rolle B gesetzt.

Rolle A hat auf alle Datensätze in der Entität Lesezugriff.
Der Lesezugriff von Rolle B ist durch einen SQL Filter auf der Tabelle beschränkt und gilt somit nur für Datensätze, dessen Feld Summe unter einem Wert von 1000 liegt.

permissions:
  read:
  - role: RolleA
  - role: RolleB
    filter: summe < 1000

Read Filter mit Expressions

Dieser SQL Filter kann auch dynamisch durch eine JavaScript Expression aufgebaut werden. Dies wird durch das Keyword $expr gekenntzeichnet.

permissions:
  read:
  - role: Rolle A
  - role: Rolle B
    filter: 
      $expr: 'summe < ' + Math.pow(10, 3)

Die Expression evaluiert hier zum gleichen Wert wie der Filter im vorherigen Beispiel, hier wird jedoch die maximale Summe durch die Potenz 10³ berechnet.

Wichtig hierbei ist, dass es sich bei dem Filter weiterhin um eine SQL Bedingung handelt. Die Expression muss also zu einem validen SQL String evaluieren.

Read Filter mit Expressions und Kontext

Innerhalb der Expressions kann auch auf den Kontext $ zugegriffen werden.

Dieser sieht bisher wie folgt aus:

So könnte ein Filter beispielsweise nur Datensätze berechtigen, denen der jeweilige Nutzer zugewiesen ist.

 permissions:
  read:
  - role: Rolle A
    filter: 
      $expr: 'zugewiesen LIKE ' + $.user.key

Update & Delete Conditions

Ähnlich zu den Read Filtern gibt es auch für die Update & Delete Methoden Berechtigungen. Diese funktionieren bei beiden Methoden identisch.

permissions:
  update:
  - role: Rolle A
  - role: Rolle B
    condition:
      sql: summe < 1000
  delete:
  - role: Rolle A
  - role: Rolle B
    condition:
      sql: summe < 1000

Hier wird die berechtigende Bedingung unter condition.sql angegeben, funktioniert allerdings analog zum read filter.

Wichtig ist hier, dass die Bedingungen sich immer auf den aktuellen Wert des Datensatzes beziehen.

Rolle B darf also einen Datensatz modifizieren, dessen aktuelle Summe unter 1000 ist, auch wenn der neue Summenwert diese Zahl übersteigt. Es ist also möglich einen Datensatz zu bearbeiten, sodass man diese Änderung nicht mehr selbst rückgängig machen kann.

Update & Delete Conditions mit Expressions

Auch hier kann anstatt einer statischen Bedingung, per JavaScript Expression die SQL Bedingung erstellt werden.

permissions:
  update:
  - role: Rolle B
    condition:
      sql: 
        $expr: 'summe < ' + Math.pow(10, 3)

Hier steht der gleiche Kontext wie im Read Filter zur Verfügung.

permissions:
  update:
  - role: Rolle B
    condition:
      sql: 
        $expr: 'zugewiesen LIKE ' + $.user.key

Update & Delete Conditions mit Scripts auf Datensatzebene

Zusätzlich zu den SQL Bedingungen stehen beim Update & Delete auch reine JavaScript Bedingungen zur Verfügung.

Hier besteht neben dem Kontextobjekt auch per Variable dataset Zugriff auf den aktuelle Wert des zu schreibenden Datensatzes.

permissions:
  update:
  - role: Rolle B
    condition:
      script: dataset.summe < 1000 && dataset.zugewiesen === $.user.key

Diese JavaScript Expressions müssen zu einem Boolean evaluieren.

Nutzbare Rollen

Welche Rollen in einem Package verwendet werden dürfen, hängt davon ab, ob es sich um ein Standardpackage oder ein Custompackage handelt.

Die Unterscheidung erfolgt über den PackageKey.

• Standardpackages und

• Custompackages => Packagekey beginnt mit C_

Rollenverwendung in Standardpackages

Innerhalb eines Standardpackages dürfen ausschließlich folgende Rollen verwendet werden:

• Eigene Rollen des aktuellen Packages

• BE-Rollen

• Rollen aus abhängigen Packages, die im dependencies-Abschnitt des be_package.yml definiert sind

Wichtige Regeln ^[1]

• Wird eine Rolle aus einem fremden Package verwendet, das nicht als Dependency definiert ist:

  • wird ein entsprechender Log-Eintrag im Codeblock-Package erzeugt

  • die Berechtigung wird ignoriert

• Wird eine Rolle ohne vorangestellten PackageKey angegeben,
  wird automatisch der eigene PackageKey vorangestellt

Beispiel:

permissions:
  - role: admin

➡ wird intern interpretiert als:

OWN.admin

(wobei OWN für den eigenen PackageKey steht)

Rollenverwendung in Custompackages

In Custompackages (PackageKey beginnt mit C_) gelten erweiterte Freiheiten:

• Es können alle Rollen verwendet werden

• Ein PackageKey ist optional

• Wird kein PackageKey angegeben, wird kein automatisches Präfix ergänzt

• Es erfolgt keine Einschränkung und kein Logging aufgrund der Rollenherkunft

Zusammenfassung

[1] : Zum aktuellen Zeitpunkt (Stand 10.0) können diese Regeln umgangen werden, indem die Berechtigung mithilfe von Patches gesetzt werden.