Eine Datenrichtlinie schreiben

Ziel

Eine Regel hinzufügen, die die Plattform nicht mitliefert – „nicht über Ihrem Genehmigungslimit“, „nicht mehr, sobald abgerechnet“ – und die Berechtigung einer Rolle danach filtern.

Voraussetzungen

• Sie sind beim Admin Control Center angemeldet, eine Umgebung ist ausgewählt, und Sie haben die Lösung geöffnet, zu der die Richtlinie gehören soll – dort befindet sich die Seite, weil die Richtlinie im Paket dieser Lösung reist.
• Sie kennen die logischen Namen der Felder, die Ihre Regel liest. Sie stehen auf der Seite „Felder“ der Tabelle.

Drei Arten, und wie Sie die richtige wählen

Die integrierten Richtlinien beantworten, welche Datensätze – meine, die meiner Einheit, die aller. Sie decken das meiste ab, was eine Rolle braucht. Schreiben Sie eine eigene, wenn sie es nicht tun, und entscheiden Sie zuerst, welche Art:

	Welche Datensätze	Regel für jeden Datensatz
Was sie ist	eine Bedingung, die in einen Datenbankfilter umgewandelt wird	eine Regel, die beim Speichern eines Datensatzes geprüft wird
Verwenden, wenn	die Antwort davon abhängt, wer fragt – seine Region, sein Team	die Antwort davon abhängt, was im Datensatz steht – ein Genehmigungslimit, ein Status
Was ein Benutzer sieht	die Datensätze sind einfach nicht da	eine Meldung, warum das Speichern abgelehnt wurde
Beispiel	Record.par_region == CurrentUser.par_region	„Dieser Betrag liegt über Ihrem Genehmigungslimit.“

Eine Richtlinie Welche Datensätze ist das bessere Werkzeug, wann immer sie passt: Datensätze, die sie ausschließt, verlassen nie den Server, daher kostet ihre Durchsetzung nichts, und es gibt keine Meldung, die jemand lesen müsste. Sie kann aber nicht alles – sie wird zu einer Abfrage und kann daher nur Felder mit Werten vergleichen.

Eine Richtlinie Regel für jeden Datensatz ist diejenige, die Total is under my approval limit („Betrag liegt unter meinem Genehmigungslimit“) ausdrücken kann, weil das keine Frage danach ist, welche Datensätze existieren. Sie läuft für jeden gespeicherten Datensatz und kann sich erklären.

Die dritte Art, Wessen Datensätze (Portal), ist überhaupt nicht für angemeldete Personen – sie beantwortet dieselbe Frage „welche Datensätze“ für einen Besucher eines Portals und wird an einer Tabelle deklariert, statt einer Rolle gewährt zu werden. Suchen Sie danach, ist dies nicht die richtige Seite: siehe Festlegen, wessen Datensätze ein Besucher sieht.

Lautet Ihre Regel eigentlich „alle müssen das ausfüllen“, brauchen Sie stattdessen eine Geschäftsregel oder einen Plug-in-Schritt an der Tabelle – diese gelten für alle, und genau das bedeutet eine Datenqualitätsregel. Eine Richtlinie gilt für jeden, der eine Berechtigung unter ihr innehat, und genau das bedeutet eine Berechtigung.

Schritte

1. Öffnen Sie Lösungen, öffnen Sie die Lösung, in der Ihre Anwendung liegt, und wählen Sie in ihrer Navigation Datenrichtlinien aus. Die Seite listet die Richtlinien auf, die diese Lösung enthält; die Standardlösung („Main“) listet jede Richtlinie der Umgebung auf.

2. Wählen Sie Neu aus.

3. Geben Sie ihr einen Anzeigenamen – so heißt sie in der Richtlinienliste auf der Rollenseite. Der logische Name füllt sich unter Ihrem Herausgeberpräfix von selbst aus; Sie können ihn jetzt ändern, aber nicht später, weil er der Name ist, auf den sich jede Gewährung bezieht.

4. Wählen Sie den Typ. Er entscheidet, was das restliche Formular abfragt, und kann danach nicht geändert werden. Die folgenden Schritte gelten für Regel für jeden Datensatz; für Welche Datensätze springen Sie zu Eine Welche-Datensätze-Richtlinie schreiben.

5. Wählen Sie Welche Datensätze. Für eine Regelrichtlinie ist das die integrierte Richtlinie, die Listen filtert, und sie ist nicht optional – siehe Warum eine Regelrichtlinie auch einen Bereich braucht. Alle Datensätze bedeutet „alles, vorbehaltlich meiner Regel“.

6. Aktivieren Sie die Operationen, bei denen die Regel geprüft werden soll. Standard sind Erstellen, Aktualisieren und Löschen. Lassen Sie Lesen ausgeschaltet, es sei denn, Sie meinen es ernst: Eine Regel, die ein Lesen ablehnt, lässt Datensätze aus Listen verschwinden, aus einem Grund, den niemand sehen kann.

7. Schreiben Sie die Regel. Sie ist in BS Lang geschrieben, derselben Sprache wie eine Geschäftsregel, und läuft gegen einen Datensatz:

   if (getValue("par_total") > currentUser("par_approvallimit")) {
     deny("That total is over your approval limit.");
   }

   Rufen Sie deny("…") auf, um abzulehnen. Eine Regel, die nichts ablehnt, erlaubt die Operation. Die Meldung, die Sie schreiben, ist das, was der Benutzer sieht – sagen Sie also, was den Datensatz akzeptabel machen würde, nicht, dass etwas falsch war.

8. Wählen Sie Speichern aus. Lässt sich die Regel nicht parsen, schlägt das Speichern fehl und nennt die Stelle. Das ist Absicht: Die Alternative wäre, es erst zu bemerken, wenn jemand von einer Regel abgewiesen wird, die nicht laufen kann.

9. Öffnen Sie die Seite Rollen der Lösung und setzen Sie die Zelle der Berechtigung, die Sie filtern möchten, auf Ihre neue Richtlinie. Sie erscheint in derselben Liste wie die integrierten.

Eine Welche-Datensätze-Richtlinie schreiben

Eine Richtlinie Welche Datensätze wird zu einer Datenbankabfrage, daher wird sie anders geschrieben und fragt nach anderen Dingen.

1. Wählen Sie die Tabelle. Anders als eine Regel wird diese Art von Richtlinie gegen die Felder einer Tabelle geschrieben, daher muss sie eine nennen – und dadurch kann die Plattform beim Speichern prüfen, ob diese Felder existieren. Sie wird nur in der Zeile dieser Tabelle auf der Rollenseite der Lösung angeboten.

2. Schreiben Sie die Bedingung – eine Bedingung, kein Skript:

   Record.par_region == CurrentUser.par_region && Record.par_status != "Closed"

   Record.<field> ist ein Feld der gewählten Tabelle. CurrentUser.<name> ist etwas über die angemeldete Person – dieselben Namen, die unter Was eine Regel lesen kann aufgeführt sind, plus jedes Feld der Benutzertabelle. Verknüpfen Sie Bedingungen mit && und ||, und gruppieren Sie sie mit Klammern.

3. Ein Vergleich mit einer Menge bedeutet „ist eines von“: Record.owning_unit == CurrentUser.UnitsAndBelow wählt Datensätze aus, die irgendwo in Ihrer Einheit oder darunter besessen werden. Sie können auch mit einer ausgeschriebenen Liste vergleichen: Record.par_status == ["Draft", "Submitted"].

4. Wählen Sie Speichern aus. Alles, was die Plattform nicht in eine Abfrage umwandeln kann, wird sofort abgelehnt, mit Begründung – siehe unten.

Was eine Bedingung nicht ausdrücken kann

Das ist bewusst eng gefasst, weil alles darin zu einer Datenbankabfrage werden muss:

Nicht erlaubt	Weil	Stattdessen
>=, <=	es dafür keinen Abfrageoperator gibt	> oder <
!(…)	eine Abfrage nicht negiert werden kann	sagen, was bleiben soll, mit !=
length(x), jede Funktion	sie ausgeführt werden müsste, und ein Filter wird nicht ausgeführt	das Feld direkt vergleichen
Record.total * 2 > 100	Arithmetik verhindert, dass eine Abfrage einen Index nutzt	mit der gemeinten Zahl vergleichen
Record.account.owner	das Folgen eines Nachschlagefelds ein Join ist, und ein versteckter Join jede Abfrage verlangsamt	ein Feld dieser Tabelle
mehrere Bedingungen in mehreren Zeilen	eine Richtlinie eine Bedingung ist	sie mit && verknüpfen

All das wird beim Speichern abgelehnt, mit Angabe der Zeile. Genau deshalb ist die Bedingungssprache klein: Eine Bedingung, die die Plattform stillschweigend nicht durchsetzen könnte, würde Datensätze zeigen, die jemand für verborgen hielt.

Was eine Regel lesen kann

Aufruf	Liefert
getValue("par_total")	Den Datensatz, wie er nach der Änderung sein wird.
getPreValue("par_total")	Den Datensatz, wie er jetzt gespeichert ist. Beim Erstellen leer.
currentUser("par_approvallimit")	Ein Feld im eigenen Benutzerdatensatz der angemeldeten Person.
isOwner()	Ob dieser Person der Datensatz gehört.
hasRole("Manager")	Ob sie eine Rolle innehat.
operation()	Create, Read, Update oder Delete.
entityName()	Den logischen Namen der Tabelle.
deny("…")	Ablehnen, mit der Begründung, die der Benutzer liest.

currentUser liest die Benutzertabelle in dieser Umgebung; um also mit einem Genehmigungslimit zu vergleichen, fügen Sie dieses Feld zuerst dort hinzu, genau wie bei jeder anderen Tabelle.

Warum eine Regelrichtlinie auch einen Bereich braucht

Eine Regel braucht einen Datensatz, der bereits geladen ist. Eine Liste ist genau das, was Sie haben, bevor Sie irgendeinen geladen haben, daher kann eine Regel keine filtern – die Plattform müsste jede Zeile abrufen, um zu entscheiden, welche Zeilen abgerufen werden sollen. Eine Richtlinie Welche Datensätze hat die umgekehrte Eigenschaft, und genau deshalb ist sie eine eigene Art und keine klügere Regel.

Eine Regelrichtlinie trägt daher beides: Welche Datensätze ist eine integrierte Richtlinie, die die Plattform in die Datenbank verlagert, und die Regel wird danach für jeden Datensatz geprüft, den jemand tatsächlich öffnet, speichert oder löscht. Setzen Sie „Welche Datensätze“ auf die engste integrierte Richtlinie, die zutrifft, und überlassen Sie den Rest der Regel.

Eine Richtlinie ausschalten

Deaktivieren Sie In Kraft und speichern Sie. Die Richtlinie existiert weiter, und jede Gewährung unter ihr funktioniert weiter – nur mit ihrer Antwort auf Welche Datensätze, ohne dass die Regel geprüft wird. Das ist der sichere Weg, während Sie herausfinden, warum eine Regel etwas ablehnt; das Löschen der Richtlinie ist es nicht, und die Plattform lässt Sie keine löschen, die eine Rolle noch verwendet.

Eine Richtlinie Welche Datensätze hat keinen solchen Schalter, und das ist kein Versehen: Sie ist die Antwort darauf, welche Datensätze, daher könnte Ausschalten nur bedeuten, alles oder nichts zu zeigen, und keines von beiden meint jemand, der sie pausieren will. Ändern Sie ihre Bedingung oder die Gewährung.

Richtlinien reisen mit der Lösung

Eine Richtlinie gehört zu einer Lösung, genau wie eine Tabelle oder ein Formular, und geht mit dieser Lösung, wenn Sie sie exportieren, und kommt mit an, wenn Sie sie anderswo importieren.

Genau darum schreibt man eine. „Eine Rechnung über meinem Genehmigungslimit darf ich nicht genehmigen“ ist Teil dessen, wie die Anwendung funktioniert, keine Einstellung, die jemand pro Umgebung konfiguriert – die App ohne sie auszuliefern, würde Test und Produktion stillschweigend erlauben lassen, was die Entwicklung abgelehnt hat, und das ist die schlimmstmögliche Richtung, in die eine Sicherheitsregel versagen kann.

Daraus folgen drei Dinge:

• Die Regel wird beim Import erneut geprüft, genau wie beim Schreiben. Ein Paket mit einer Richtlinie, die nicht mehr kompiliert, wird beim Import abgelehnt, statt erst von der ersten Person entdeckt zu werden, die sie fälschlich abweist.
• Eine ausgeschaltet ausgelieferte Richtlinie kommt ausgeschaltet an. Deaktivieren Sie In Kraft bei einer Regel, die vor einem Go-live vorbereitet wird, und die Zielumgebung erhält sie in diesem Zustand; der Import schaltet keine Regel ein, die noch niemand angefordert hat.
• Das Deinstallieren der Lösung entfernt die Richtlinie – und die darunter vorgenommenen Gewährungen; das ist das einzige Mal, dass diese ohne Nachfrage verschwinden. Eine Gewährung, deren Richtlinie fehlt, würde sonst alles ablehnen, was sie einmal erlaubt hat, ohne dass auf dem Bildschirm steht, warum.

Wem unter der Richtlinie etwas gewährt wird, reist nicht mit: Das nennt Ihre Leute und bleibt in der Umgebung, in der Sie es entschieden haben.

Fehlerbehebung

• „Die Regel der Richtlinie lässt sich nicht parsen.“ – ein Tippfehler in der Regel. Die Meldung nennt die Stelle.
• „… ist eine der eigenen Richtlinien der Plattform.“ – Sie haben einen integrierten Namen verwendet. Eigene Richtlinien tragen Ihr Herausgeberpräfix.
• „… filtert noch Berechtigungen von N Rolle(n).“ – ändern Sie zuerst diese Gewährungen auf der Rollenseite der Lösung. Das Löschen der Richtlinie würde jetzt jede davon ablehnen.
• Niemand kann in der Tabelle etwas speichern. – prüfen Sie den Vergleich der Regel. Eine Regel, die ein nicht existierendes Feld liest, erhält einen leeren Wert, und "" > 100 ist nicht der Vergleich, den Sie meinten. Deaktivieren Sie In Kraft, während Sie es klären.
• Die Regel scheint nie zu laufen. – prüfen Sie die aktivierten Operationen und ob die Gewährung der Rolle tatsächlich auf Ihre Richtlinie zeigt und nicht auf eine integrierte.
• Ein Benutzer wird mit einer Meldung über eine Richtlinie abgewiesen, die nicht ausgewertet werden konnte. – die Regel konnte nicht ausgeführt werden. Die Operation wird abgelehnt statt erlaubt, weil eine Regel, die nicht laufen konnte, nicht gesagt hat, dass der Datensatz akzeptabel ist. Korrigieren Sie die Regel oder deaktivieren Sie In Kraft.
• „Diese Bedingung kann nicht in eine Abfrage umgewandelt werden.“ – eine Welche-Datensätze-Bedingung verwendet etwas außerhalb dessen, was eine Abfrage ausdrücken kann. Die Meldung nennt die Zeile und was stattdessen zu verwenden ist; die Tabelle oben führt alles auf.
• Meine Welche-Datensätze-Richtlinie wird in der gewünschten Zeile nicht angeboten. – sie ist gegen eine Tabelle geschrieben, wird also nur in der Zeile dieser Tabelle angeboten und nie bei Alle Tabellen. Schreiben Sie eine eigene Richtlinie für die andere Tabelle.
• Eine Welche-Datensätze-Richtlinie zeigt niemandem etwas. – eine Bedingung, die zu nichts aufgelöst wird, wählt nichts aus; das ist die sichere Richtung, die die Plattform immer einschlägt. Prüfen Sie die Feldnamen und – wenn Sie mit einer Menge wie CurrentUser.Teams verglichen haben –, ob die Person tatsächlich in einem Team ist.

Verwandte Szenarien

• Festlegen, wessen Datensätze ein Besucher sieht
• Einer Rolle Zugriff auf Datensätze gewähren.
• Ändern, wem ein Datensatz gehört.