Direkt zum Hauptinhalt

Festlegen, wessen Datensätze ein Besucher sieht

Ziel​

Legen Sie einmal fest, dass die Datensätze einer Tabelle dem Kunden gehören, den sie nennen, sodass jeder angemeldete Portalbesucher seine eigenen sieht und die von niemand anderem – über jede benutzerdefinierte API, die Ihr Portal verwendet, und über jede, die später jemand hinzufügt.

Das Problem, das es löst​

Ihr Portal liest über benutzerdefinierte APIs, und ein Skript kann bereits fragen, wer aufruft:

var mine = runQuery({
  entity: 'par_ticket',
  filter: { connector: 'And', conditions: [
    { field: 'par_customer', operator: 'Equals', value: portalCustomerId() }
  ]}
});

Das funktioniert. Es funktioniert, seit sich Besucher anmelden können. Das Problem ist, dass es in jedem Skript erneut geschrieben werden muss und dass man nicht sieht, wenn es fehlt: Eine API ohne diesen Filter sieht genauso aus wie eine API mit ihm, liefert ganz unbekümmert Zeilen und zeigt einem Kunden die Tickets eines anderen Kunden.

Eine Portal-Beziehungsregel holt diesen Satz aus den Skripten heraus und legt ihn an die Tabelle.

Bevor Sie beginnen​

  • Ihr Portal ist auf Angemeldete Personen eingestellt – siehe Besucher zur Anmeldung auffordern. Eine Tabelle mit einer Beziehungsregel kann von einem Portal, das jeder öffnen kann, nicht gelesen werden, denn es gäbe niemanden, dem ihre Datensätze gehören könnten.
  • Ihre Tabelle hat ein Feld, das den Kunden enthält – ein Nachschlagefeld auf Account ist die übliche Form, denn genau das ist das Unternehmen eines Besuchers.
  • Ihre Besucher sind Mitglieder eines Kunden. Wer sich registriert hat und noch keinem Unternehmen beigetreten ist, passt auf gar nichts – das ist die sichere Antwort und vermutlich nicht die, die Sie ihm zeigen möchten.

Schritte​

  1. Öffnen Sie Ihre Lösung und wählen Sie Datenrichtlinien aus.

  2. Drücken Sie Neu und geben Sie einen Namen ein – Tickets gehören ihrem Kunden.

  3. Setzen Sie Typ auf Wessen Datensätze (Portal).

  4. Wählen Sie die Tabelle aus.

  5. Schreiben Sie die Bedingung:

    Record.par_customer == Portal.CustomerId

    Es ist der Code-Editor der Plattform: Ein Name, den er nicht kennt, etwa Portal.CustomrId, wird schon beim Tippen unterstrichen und nicht erst beim Speichern abgelehnt.

  6. Lassen Sie In Kraft angehakt, und drücken Sie Speichern.

Das ist die ganze Funktion. Nichts sonst muss gewährt, referenziert oder eingeschaltet werden.

Womit Sie vergleichen können​

Fünf Angaben über den angemeldeten Besucher, und die Bedingung muss mindestens eine davon erwähnen – sonst sagt sie nicht, wessen Datensätze das sind.

Was es ist
Portal.CustomerIdDas Unternehmen, zu dem er gehört. Das verwenden Sie fast immer
Portal.ContactIdSein eigener Kontaktdatensatz, sofern er einen hat
Portal.UserIdDer Portalbenutzer selbst
Portal.EmailSeine E-Mail-Adresse
Portal.Role"Owner", "Billing" oder "Member" in seinem Unternehmen

Sie können Bedingungen mit && und || verknüpfen und auch die eigenen Felder der Tabelle vergleichen:

Record.par_customer == Portal.CustomerId && Record.par_status != "Draft"
CurrentUser ist nicht der Besucher

In einem Portal ist der „angemeldete Benutzer“ der eigene Server des Portals – eine Identität, die sich alle teilen, die es verwenden. Deshalb kann eine Beziehungsregel CurrentUser nicht lesen, und deshalb kann eine gewöhnliche Datenrichtlinie Portal nicht lesen. Der Bildschirm lehnt beides beim Speichern ab.

Was sie genau tut​

  • Jeder Lesevorgang wird eingeschränkt, gleich welche benutzerdefinierte API fragt. Sie können den Filter aus den Skripten löschen, die einen haben; Sie müssen es aber nicht.
  • Ein Anlegen, das einen Datensatz einem anderen Kunden zuordnen würde, wird abgelehnt – geprüft am Datensatz, wie er tatsächlich gespeichert würde. Ebenso eine Bearbeitung, die einen Datensatz verschieben würde.
  • Ein Besucher, der zu keinem Unternehmen gehört, sieht nichts – auch nicht die Datensätze, deren Kunde leer ist.
  • Eine Regel pro Tabelle. Wenn Sie eine ersetzen müssen, schreiben Sie die neue mit nicht angehaktem In Kraft und tauschen Sie die beiden dann aus.

Was sie nicht tut​

Sie macht die Tabelle nicht privat. Ihre eigenen Leute, an der Plattform angemeldet, sehen, was ihre Sicherheitsrolle sie sehen lässt, genau wie zuvor. Die Regel betrifft Portalbesucher; sie ist kein Ersatz dafür, einer Rolle Zugriff auf Datensätze zu gewähren.

Sie wird keiner Rolle gewährt, und der Bildschirm lehnt ab, wenn Sie es versuchen. Sie gehört zur Tabelle. Genau darum geht es – eine Regel, an deren Gewährung Sie denken müssen, ist eine Regel, deren Gewährung Sie vergessen können.

Fehlerbehebung​

„Eine Portal-Beziehungsregel muss angeben, welche Datensätze dem Besucher gehören.“ Ihre Bedingung erwähnt Portal nirgends. So wie sie geschrieben ist, ist sie ein gewöhnlicher Filter, und das ist etwas anderes.

„…ist bereits die Portal-Beziehungsregel für…“ Eine einzige Regel entscheidet, wessen Datensätze eine Tabelle enthält. Schalten Sie die andere aus, oder bearbeiten Sie sie, statt eine zweite hinzuzufügen.

Ein Besucher sieht überhaupt nichts. Prüfen Sie, ob er Mitglied eines Kunden ist und ob das Feld in Ihrer Bedingung dasjenige ist, das tatsächlich den Kunden enthält – eine Bedingung, die das falsche Feld vergleicht, passt bewusst auf nichts statt auf alles.

Das Portal lässt sich mit der Tabelle auf seiner Liste nicht speichern. Das Portal ist auf Jeder eingestellt. Eine Tabelle, deren Datensätze einem angemeldeten Besucher gehören, braucht ein Portal, das einen hat.

Verwandte Seiten​