Einführung in App Builder - Anhang D: Sicherheit in App Builder (Fortgeschritten)

Dies ist der vierte und letzte Anhang der Tutorial-Serie Einführung in App Builder. Diese Anhänge ergänzen die Lektionen der Serie und bieten detailliertere Informationen zu eingeführten Konzepten.

In dieser Lektion erkunden wir die Sicherheitsebene von App Builder – den Bereich, in dem wir kontrollieren, wer auf unsere Anwendung zugreifen kann, und welche Teile ihrer Daten jeder Benutzer sehen oder ändern darf.

Rollen

Rollen sind die Art, wie App Builder Berechtigungen für eine Datenquelle organisiert. Eine Rolle kann Lesen-, Einfügen-, Aktualisieren- und Löschen-Berechtigungen für eine Tabelle oder ein Geschäftsobjekt erhalten, und Benutzer erhalten ihre Rollen indirekt durch die Mitgliedschaft in einer oder mehreren Sicherheitsgruppen. Gruppen organisieren Benutzer; Rollen organisieren Berechtigungen. Siehe Rollen für eine vollständige Erklärung, was eine Rolle ist, oder Berechtigungen und Genehmigungen dafür, wie jede Berechtigung beeinflusst, was ein Benutzer sehen und tun kann.

Erstelle eine Reihe von Rollen für unsere Northwinds-Datenquelle, die typische Aufgabenbereiche in einem Unternehmen widerspiegeln: Superuser, Schreibgeschützt, Betrieb, Personalwesen und Vertrieb. Jede führt eine andere Möglichkeit ein, Berechtigungen zu erteilen – von breiten Beschleunigern bis zur präzisen Kontrolle Objekt für Objekt.

Superuser

Erstelle eine Superuser-Rolle, indem du diese Schritte befolgst:

1. Wähle in App Workbench > Datenquellen die Quelle Northwinds (Standard) aus.

2. Klicke im Abschnitt Business Logic Layer auf Rollen. Das Dialogfeld Rollen wird geöffnet.

3. Klicke auf + Superuser. App Builder erstellt automatisch eine Rolle namens Superuser mit vollständigen Berechtigungen für jede Tabelle und jedes Geschäftsobjekt in der Datenquelle.

Schreibgeschützt

Erstelle nun eine Rolle Schreibgeschützt, indem du diese Schritte befolgst:

1. Klicke auf + Rolle.

2. Gib im Feld Name Schreibgeschützt ein.

3. Gib im Feld Beschreibung eine Beschreibung ein, z. B. Schreibgeschützter Zugriff auf alle Northwinds-Daten.

4. Klicke auf Speichern.

5. Erweitere das Akkordeon Tabellen und klicke auf Lesen erteilen, um der Rolle Schreibgeschützt Lesezugriff auf alle Tabellen auf einmal zu gewähren.

6. Erweitere das Akkordeon Geschäftsobjekte und klicke dann auf Lesen erteilen, um dasselbe für alle Geschäftsobjekte zu tun.

Betrieb

Die Rolle Betrieb verwaltet den Kernbestand, die Beziehungen zu Lieferanten und die Auftragsabwicklung, die das Geschäft im Hintergrund am Laufen halten. Sie verwaltet Produktkategorien, aktualisiert Preise und Lagerbestände, verwaltet Lieferantenkontakte und weist Versandcarrier für die Lieferung von Kundenaufträgen zu.

1. Klicke auf + Rolle.

2. Gib im Feld Name Betrieb ein.

3. Klicke auf Speichern.

4. Klicke auf das Symbol Seiten in der Zeile Betrieb – eine weitere Möglichkeit, die Rollenerstellung zu beschleunigen: Statt Berechtigungen Tabelle für Tabelle zu erteilen, wählst du aus, welche Seiten eine Rolle benötigt, und App Builder erteilt die zugrunde liegenden Berechtigungen, von denen diese Seiten abhängen.

5. Wählen Sie die Seiten Suppliers, Supplier, Shippers, Shipper, Products, Product und Categories aus und gewähren Sie vollständigen Zugriff (Read, Insert, Update und Delete) auf alle.

6. Wählen Sie die Seiten Home, Customers, Customer, Orders, Order, Employees und Employee aus und gewähren Sie ausschließlich Read-Zugriff auf alle, da Operations diese Daten einsehen muss, ohne sie ändern zu können.

HR

Die Rolle HR verwaltet Mitarbeiterdatensätze, deren regionale Zuordnungen und die Organisationsstruktur des Unternehmens. Sie benötigt präzisen, granularen Zugriff anstelle von breiten Tabellen- oder Seiten-Berechtigungen.

1. Klicken Sie auf + Role.

2. Geben Sie im Feld Name HR ein.

3. Klicken Sie auf Save.

4. Klicken Sie in der Rolle-Ansicht auf + Permission, um einzelne Objekte nacheinander hinzuzufügen.

5. Fügen Sie die Regeln Employee (Source), Region (Source), Region (List) und Employee (Network) hinzu, um HR vollständigen Zugriff auf jede zu gewähren. Das Hinzufügen einer Berechtigung auf diese Weise gewährt standardmäßig vollständigen Zugriff (Read, Insert, Update und Delete).

Übungsaufgabe: Erstellen Sie die Rolle Sales

Die Rolle Sales muss Kunden und Bestellungen verwalten, Produkt-, Kategorie-, Versand- und Mitarbeiterdaten einsehen und die von uns erstellten Berichte anzeigen. Sie sollte keinen Zugriff auf administrative Daten wie Lieferanten oder die Parametertabelle haben.

Erstellen Sie mithilfe der gleichen Pages-Symbolschaltfläche, die Sie für Operations verwendet haben, eine Rolle Sales mit folgendem Zugriff:

• Vollständiger Zugriff auf die Seiten Customers, Customer, Orders und Order.
• Read-Zugriff auf die Seiten Products, Product, Categories, Shippers, Shipper, Employees, Employee und Order Total by Employee.

Wählen Sie nicht die Seiten Suppliers, Supplier oder Parameter aus, damit Sales keinen Zugriff darauf hat.

Application Groups

Sobald Rollen vorhanden sind, werden Berechtigungen standardmäßig restriktiv: Ein Benutzer erhält die Berechtigungen einer Rolle nur, wenn seine Gruppen ihm diese Rolle gewähren. Da sich Ihr eigenes Benutzerkonto noch in keiner Gruppe befindet, sperrt Sie das Erstellen der oben angegebenen Rollen aus Ihrer eigenen Anwendung aus, es sei denn, Sie verbinden sie mit echten Benutzern. Weitere Informationen finden Sie unter How roles affect application access.

1. Klicken Sie auf der Seite Roles auf Application Groups.

2. Klicken Sie auf Create.

3. Verwenden Sie im Feld Name das Muster [App Name] [Role], beispielsweise Northwinds Superuser. Beschreiben Sie im Feld Description, wer zu der Gruppe gehört.

4. Klicken Sie auf das Häkchen, um zu speichern.

5. Klicken Sie im Bereich Roles neben der Rolle Superuser auf Grant, um sie mit der Application Group Northwinds Superuser zu verbinden.

Übungsaufgabe: Erstellen Sie die restlichen Application Groups

Wiederholen Sie die obigen Schritte, um eine Application Group für jede der anderen Rollen zu erstellen, die Sie erstellt haben: Read Only, Operations, HR und Sales.

Fügen Sie sich abschließend selbst zur Gruppe Northwinds Superuser hinzu, damit Sie keinen Zugriff auf die Anwendung verlieren, die Sie erstellt haben:

1. Navigieren Sie zu IDE > User Management > Groups.

2. Suchen Sie die Gruppe Northwinds Superuser und klicken Sie auf + Membership.

3. Wählen Sie Ihren Benutzer aus.

4. Klicken Sie auf das Häkchen, um zu speichern.

Sie sollten jetzt über vollständige Berechtigungen verfügen, da Ihr Benutzer zur Gruppe Northwinds Superuser gehört, die Ihnen die Rolle Superuser gewährt.

Reach

Reach ist die Implementierung von Sicherheit auf Zeilenebene durch App Builder. Während die gerade erstellten Rollen steuern, welche Operationen ein Benutzer auf ein Datenobjekt als Ganzes ausführen kann, steuert Reach, welche Zeilen dieses Datenobjekts ein Benutzer überhaupt sehen oder beeinflussen kann. Reach wird von der App Builder-Geschäftsengine implementiert, daher funktioniert es unabhängig von der zugrunde liegenden Datenbank gleich.

Reach basiert auf drei Konzepten:

• Reach-Regel: Eine reguläre Geschäftsregel, wie die, die wir in Appendix B erstellt haben, die bestimmt, auf welche Datensegmente ein Benutzer zugreifen kann. Reach-Regeln verwenden typischerweise die who()-Funktion von mvSQL, um den aktuellen Benutzer mit den Daten zu korrelieren, die dieser sehen darf.

• Reach-Token: Die einzelne Spalte, die in einer Reach-Regel ausgewählt wird und durch den Spaltenverwendungstyp Reach Token gekennzeichnet ist. Diese Spalte identifiziert ein Datensegment, z. B. eine Region oder eine Geschäftseinheit.

• Reach-Registrierung: Die Konfiguration, die eine Reach-Regel an ein Datenobjekt anfügt. Sie gibt an, welche Spalte in diesem Datenobjekt dem Token der Reach-Regel entspricht, und optional, auf welche Rolle sich die Einschränkung bezieht.

Denken Sie an Lektion 5 zurück, in der wir die Spalte RegionID zu unserer Tabelle Employee hinzugefügt haben und einige Mitarbeiter der Region East Coast sowie andere der Region West Coast zugewiesen haben. Wir werden diese gleiche Konfiguration verwenden, um die Seite Employees so einzuschränken, dass jeder Benutzer nur Mitarbeiter aus seiner eigenen Region sieht.

Zunächst benötigen wir eine Möglichkeit, den Mitarbeiterdatensatz zu identifizieren, der dem aktuell angemeldeten Benutzer entspricht. Wir verwenden die UserID des Mitarbeiters statt seines Benutzernamens, da sich ein Benutzername im Laufe der Zeit ändern kann, während eine UserID für die Lebensdauer des Kontos konstant bleibt.

1. Verknüpfen Sie die integrierte Datenquelle Vinyl (Sealed) mit Ihrer Anwendung, um ihre öffentlichen Datenobjekte zu nutzen: Klicken Sie unter App Workbench > Data Sources auf + Data Source. Das Dialogfeld Add a Source to your application wird geöffnet.

2. Wählen Sie Link to existing source aus, suchen Sie dann Vinyl (Sealed) in der Liste der vorhandenen Datenquellen und wählen Sie es aus.

3. Klicken Sie auf Link Sources.

4. Klicken Sie auf Done.

Geben wir der Tabelle Employee nun eine entsprechende Spalte.

1. Suchen Sie unter App Workbench > Tables die Tabelle Employee und öffnen Sie sie.

2. Klicken Sie auf + Column.

3. Geben Sie der neuen Spalte den Namen UserID. Achten Sie darauf, dass im Bereich Data Types im Feld Logical die Option Unique ID ausgewählt ist, was das Feld Physical automatisch auf UUID setzt.

4. Klicken Sie auf Save.

5. Suchen Sie unter App Workbench > Rules die Regel Employee (Source) und öffnen Sie sie.

6. Suchen Sie auf der Registerkarte Tables die Spalte UserID und aktivieren Sie ihr Kontrollkästchen, um sie einzubeziehen.

Statt diesen Wert manuell einzugeben, fügen wir ein Steuerelement hinzu, damit es über die Benutzeroberfläche festgelegt werden kann – genauso, wie es in einer echten Produktionsumgebung erforderlich wäre.

1. Suchen Sie unter App Workbench > Pages die Seite Employee und öffnen Sie sie.

2. Klicken Sie im Bereich Page Panel Layout auf Controls.

3. Klicken Sie auf + Control.

4. Wählen Sie im Menü Column die Option UserID aus und klicken Sie auf Next.

5. Wählen Sie unter Source das Objekt User_Read aus – das öffentliche Datenobjekt, das von der oben verknüpften Datenquelle Vinyl (Sealed) bereitgestellt wird. Die Auswahl Key (Column) sollte UserId und Title (Column) sollte UserName sein.

6. Klicken Sie auf Next und dann auf Finish.

7. Navigieren Sie zur Seite Employees, öffnen Sie einen bereits einer Region zugewiesenen Mitarbeiter und verwenden Sie das neue Feld, um den Benutzer auszuwählen, mit dem Sie sich bei App Builder anmelden.

Erstellen wir jetzt die Reach-Regel.

1. Klicken Sie unter App Workbench > Rules auf + Rule.

2. Geben Sie im Feld Name Employee (Region Access) ein.

3. Wählen Sie im Feld Purpose die Option Reach aus.

4. Wählen Sie im Feld Target die Option Employee aus.

5. Klicken Sie auf Create.

6. Wählen Sie auf der Registerkarte Tables die Optionen RegionID und UserID zusätzlich zur bereits ausgewählten Primärschlüsselspalte EmployeeID aus.

7. Klicken Sie auf der Registerkarte Where auf + Where Clause. Geben Sie im Feld Left Expression E.UserID ein, wählen Sie im Feld Operator = aus, und geben Sie im Feld Right Expression who('userid') ein. Klicken Sie auf Save.

8. Doppelklicken Sie auf der Registerkarte Columns auf die Spalte RegionID. Legen Sie im Abschnitt Advanced den Column Usage Type auf Reach Token fest. Klicken Sie auf Save.

9. Klicken Sie im Bereich Rule auf Results, um zu bestätigen, dass die Regel eine einzelne Zeile zurückgibt, die die Region des Mitarbeiterdatensatzes enthält, den Sie zuvor ausgewählt haben.

Registrieren Sie abschließend diese Reach-Regel, um das Geschäftsobjekt Employee (Source) zu beschränken.

1. Suchen Sie in App Workbench > Rules die Regel Employee (Source) und öffnen Sie sie.

2. Klicken Sie im Bereich Rule auf More > Edge Case. Das Dialogfeld Edge Case Settings wird geöffnet.

3. Klicken Sie auf Reach. Das Dialogfeld Reach Registration wird geöffnet.

4. Klicken Sie auf Create.

5. Wählen Sie im Feld Rule die Option Employee (Region Access) aus.

6. Wählen Sie im Feld Binding Column die Option RegionID aus.

7. Lassen Sie das Feld Role vorerst leer, damit die Beschränkung für alle Benutzer gilt, einschließlich Ihnen selbst, während wir sie testen. Stellen Sie sicher, dass Active aktiviert ist.

8. Klicken Sie auf Save.

Besuchen Sie die Seitenvorschau Employees. Sie sollten jetzt nur Mitarbeiter sehen, die eine Region mit dem Mitarbeiterdatensatz teilen, den Sie zuvor ausgewählt haben, anstelle der gesamten Liste.

Übungszeit: Regionalen Zugriff auf Kunden erweitern

Mitarbeiter sind nicht die einzigen Northwinds-Daten, die von regionalem Zugriff profitieren könnten. Wenden Sie die gleiche Beschränkung auf die Tabelle Customer an.

1. Führen Sie die oben für die Tabelle Employee verwendeten Schritte aus: Fügen Sie eine Spalte RegionID zur Tabelle Customer hinzu, fügen Sie sie zur Regel Customer (Source) hinzu, und fügen Sie ein Listensteuerelement Region (aus Region (List)) zur Seite des Popups Customer hinzu. Verwenden Sie das neue Steuerelement, um einer Anzahl von Kundendatensätzen eine Region zuzuweisen.

2. Erstellen Sie eine neue Reach-Regel mit dem Namen Customer (Region Access), wobei Purpose auf Reach und Target auf Customer gesetzt ist. Klicken Sie auf der Registerkarte Tables auf + Tables, um die Tabelle Employee hinzuzufügen, verbunden mit Customer über RegionID.

3. Verwenden Sie dieselbe Where Clause und dieselben Reach Token-Spaltenverwendungstypen aus der Regel Employee (Region Access) wieder. Wählen Sie dieses Mal RegionID aus der Tabelle Employee aus. In Kombination mit dem Join gibt die Regel nun nur Kunden zurück, die eine Region mit dem aktuell angemeldeten Mitarbeiter teilen.

4. Registrieren Sie die neue Regel auf dem Geschäftsobjekt Customer (Source), indem Sie sie diesmal an die Spalte RegionID der Tabelle Customer selbst binden.

5. Besuchen Sie die Seitenvorschau Customers, um zu bestätigen, dass nur Kunden aus Ihrer Region sichtbar sind.

Block

Der Spaltennutzungstyp Block verhindert, dass eine Zeile bearbeitet, gelöscht oder beides wird. Im Gegensatz zu Rollen, die für ein gesamtes Datenobjekt gelten, und Reach, das die Zeilensichtbarkeit steuert, kontrolliert Block, was ein Benutzer mit einer bereits sichtbaren Zeile tun kann. Ein Datenobjekt kann nur eine Block-Spalte verwenden, und ihr Wert bestimmt die Einschränkung:

Eine Block-Spalte kann auf zwei verschiedenen Ebenen hinzugefügt werden, und wo diese hinzugefügt wird, bestimmt, wie weit die Einschränkung reicht. Das Hinzufügen zu einer Tabelle in der Datenschicht wendet die Einschränkung global an, überall dort, wo die Tabellendaten in der App verwendet werden. Das Hinzufügen als Ausdruck auf einem Geschäftsobjekt in der Logikschicht, wie wir unten tun werden, wendet die Einschränkung nur dort an, wo dieses spezifische Geschäftsobjekt verwendet wird.

Anstatt diese Zahlen direkt zurückzugeben, kann man auch die Funktion BlockOption() mvSQL verwenden, die die besser lesbaren Werte None, Edit, Delete und EditAndDelete akzeptiert.

Sobald eine Bestellung versendet ist, sollten sich ihre Positionen nicht mehr ändern. Blockieren wir die Bearbeitung und das Löschen von OrderDetail-Zeilen für jede Bestellung, die bereits ein ShippedDate hat.

1. In App Workbench > Rules die Regel OrderDetail (Source) suchen und öffnen.

2. Im Reiter Tables auf + Tables klicken und die Tabelle Order hinzufügen.

3. Im Reiter Joins sollte App Builder bereits einen inneren Join zwischen OrderDetail und Order auf OrderID erstellt haben. Wenn nicht, diesen erstellen.

4. Im Reiter Columns auf + Column klicken. Im Feld Column or Expression IIF(O.ShippedDate IS NOT NULL, BlockOption(EditAndDelete), BlockOption(None)) eingeben. Im Feld Alias Block eingeben.

5. Auf Save klicken.

6. Doppelt auf die neue Spalte Block klicken. Im Abschnitt Advanced den Column Usage Type auf Block setzen. Auf Save klicken.

Die Vorschau der Seite Orders besuchen und eine Bestellung auswählen, die bereits ein ShippedDate hat. Im Panel Order Details sollten die Bearbeitungs- und Löschsymbole nicht mehr für irgendeine Zeile angezeigt werden. Eine Bestellung auswählen, die noch nicht versendet wurde, und diese Symbole sollten wie gewohnt verfügbar sein.

Übungszeit: Block die Bestellung selbst

Positionen sind nicht die einzigen Datensätze, die sich nach dem Versand nicht mehr ändern sollten. Die gleiche Logik direkt auf die Regel Order (Source) anwenden: eine Block-Spalte mit dem Ausdruck IIF(ShippedDate IS NOT NULL, BlockOption(EditAndDelete), BlockOption(None)) hinzufügen und ihren Column Usage Type auf Block setzen. Da ShippedDate bereits zur Tabelle Order gehört, ist diesmal kein Join erforderlich. Die Ergebnisse in der Vorschau der Seite Orders testen: versendete Bestellungen sollten ihre eigenen Bearbeitungs- und Löschsymbole nicht mehr anzeigen.

Capability bindings

Capability bindings sind ein spezialisierter Bindungstyp, der den funktionalen Zustand eines untergeordneten Panels an die Daten eines übergeordneten Panels oder eines Seitendatenobjekts verknüpft. Sie können verwendet werden, um Steuerelemente auszublenden oder zu deaktivieren, ähnlich wie Block, aber mit einem wichtigen Vorteil: Capability bindings können auch die Schaltfläche Create eines Panels beeinflussen. Dies ist etwas, das Block nicht kann, da diese Schaltfläche unabhängig von einer bestimmten Zeile vorhanden ist.

Eine capability-gebundene Spalte kann verschiedene Werte zurückgeben, um den Zustand eines gebundenen Steuerelements zu steuern:

Wir verwenden dies, um die Schaltfläche Erstellen im Panel Bestelldetails zu deaktivieren, sobald die übergeordnete Bestellung bereits versendet wurde. Dies verhindert, dass neue Positionen zu einer bereits verschickten Sendung hinzugefügt werden.

1. Suchen und öffnen Sie in App Workbench > Regeln die Regel Order (Source).

2. Klicken Sie auf der Registerkarte Spalten auf + Spalte. Geben Sie im Feld Spalte oder Ausdruck IIF(ShippedDate IS NOT NULL, 2, 0) ein. Geben Sie im Feld Alias LockNewDetails ein.

3. Klicken Sie auf Speichern.

4. Öffnen Sie die Seite Bestellungen und wählen Sie Aktionsbereich > Live Designer.

5. Klicken Sie auf das Bindungsspaltensymbol im Panel Bestelldetails. Das Dialogfeld Bindungsspalten wird geöffnet:

   

6. Klicken Sie auf + Bindung und legen Sie das Feld Typ auf Funktion fest.

7. Wählen Sie im Feld Übergeordnet die Option LockNewDetails.

8. Wählen Sie im Feld Systemereignis die Option Einfügen.

9. Klicken Sie auf Speichern.

Besuchen Sie die Vorschau der Seite Bestellungen und wählen Sie eine versandte Bestellung aus. Die Schaltfläche Erstellen im Panel Bestelldetails sollte jetzt deaktiviert sein. Wählen Sie eine Bestellung aus, die noch nicht versendet wurde, und die Schaltfläche sollte wieder anklickbar sein.

Übungszeit: Ausblenden statt Deaktivieren

Funktionsbindungen unterstützen andere Zustände als nur das Deaktivieren eines Steuerelements. Ein Wert von 1 blendet ein Steuerelement vollständig aus, anstatt es zu deaktivieren. Ändern Sie den Ausdruck LockNewDetails zu IIF(ShippedDate IS NOT NULL, 1, 0) und testen Sie die Ergebnisse: Die Schaltfläche Erstellen im Panel Bestelldetails sollte auf versandten Bestellungen jetzt vollständig verschwinden, anstatt sichtbar aber unbrauchbar zu bleiben.

Bedingte Formatierung

Block- und Funktionsbindungen decken die integrierten Arten ab, wie Benutzer mit einem Datensatz interagieren: die Bearbeitungs- und Löschsymbole sowie die Schaltfläche Erstellen eines Panels. Allerdings umgehen alle Schaltflächen, die an ein benutzerdefiniertes Ereignis angebunden sind, wie die Schaltflächen Menge Plus und Menge Minus, die wir in Anhang B hinzugefügt haben, beide. Weder Block noch das Systemereignis einer Funktionsbindung gilt für ein benutzerdefiniertes Ereignis, daher funktionieren diese Schaltflächen auch bei versandten Bestellungen weiterhin und ermöglichen es Benutzern, eine Menge zu ändern, die nicht mehr bearbeitbar sein sollte.

Die bedingte Formatierung ermöglicht es Ihnen, ein Steuerelement basierend auf dem Wert einer beliebigen Spalte auszublenden oder zu deaktivieren, unabhängig davon, an welches Ereignis es angebunden ist. Wir verwenden dies, um die Schaltfläche Menge Minus zu deaktivieren, sobald eine Bestellung versendet wurde.

Die Spalte ShippedDate gehört jedoch zur Tabelle Order, nicht zu OrderDetail, und die obige Übung Block referenzierte sie nur in einem Ausdruck, anstatt sie als Spalte für sich selbst hinzuzufügen. Da die Schaltfläche Menge Minus im Panel Bestelldetails vorhanden ist, das von OrderDetail (Source) stammt, fügen Sie ShippedDate zunächst dieser Regel hinzu, damit sie für die bedingte Formatierung verfügbar ist.

1. Suchen und öffnen Sie in App Workbench > Regeln die Regel OrderDetail (Source).

2. Suchen Sie auf der Registerkarte Tabellen die Tabelle Order, die bereits in der obigen Übung Block verbunden wurde, und aktivieren Sie das Kontrollkästchen für ihre Spalte ShippedDate.

3. Klicken Sie auf Speichern.

4. Öffnen Sie die Seite Bestellungen und wählen Sie Aktionsbereich > Live Designer.

5. Wählen Sie die Schaltfläche aus, die das Ereignis Menge Minus ausführt.

6. Klicken Sie auf Mehr > Stile.

7. Klicken Sie auf + Bedingte Formatierung.

8. Wählen Sie im Feld Quellspalte die Option ShippedDate.

9. Wählen Sie im Feld Operator die Option Ist nicht Null.

10. Wählen Sie im Feld Status die Option Deaktiviert.

11. Klicken Sie auf Speichern.

Besuchen Sie die Vorschau der Seite Bestellungen und wählen Sie eine versandte Bestellung aus. Die Schaltfläche Menge Minus sollte jetzt deaktiviert sein. Wählen Sie eine Bestellung aus, die noch nicht versendet wurde, und die Schaltfläche sollte wieder anklickbar sein.

Übungszeit: Bedingte Formatierung erweitern

Wiederholen Sie die obigen Schritte für die Schaltfläche, die das Ereignis Menge Plus ausführt.

Wenden Sie dann die gleiche Einschränkung auf die Schaltfläche Delete Order Details im Panel Orders an, diesmal jedoch mit der Einstellung State auf Hidden statt Disabled, um zu sehen, wie sich die beiden Zustände unterscheiden. Sobald eine Bestellung versendet wurde, sollte die Schaltfläche vollständig verschwinden, anstatt sichtbar zu bleiben, aber nicht nutzbar zu sein.

Weitere Lernmöglichkeiten

Dies beendet diesen ausführlichen Überblick über die Details der Sicherheitsebene von App Builder. Falls noch nicht geschehen, lesen Sie Appendix A für einen detaillierteren Blick auf die Datenschicht, Appendix B für die Geschäftslogikschicht oder Appendix C für die UI-Schicht.

Um mehr über App Builder zu erfahren, besuchen Sie Jitterbit University.