Eine "Eigene Übersicht" für Benutzer wird neu angelegt und mit der rechts abgebildeten Konfiguration für die Einschränkung versehen:

• Die linken Seite der Feld Einschränkung adressiert das Feld "Erstellt von" (creatorId) des Benutzers, in dem Long-Werte enthalten sind, die als Referenz auf ein Benutzer- bzw. Gastbenutzerkonto gelten.
  
  

• Auf der rechten Seite der Feld Einschränkung wird der Benutzer der Session-Wertauflöser verwendet, um das Benutzer- oder Gastbenutzerkonto zu ermitteln, auf das sich die aktuelle Sitzung bezieht. Der verkettete Objekt-Feld-Wertauflöser liest das Feld "ID" (id) des Kontos, die hier als Suchkriterium für die Übersicht dient.

►HINWEIS◄ Die Schnittstelle gibt den eigentlich positiven Wert der ID eines Gastbenutzerkontos als negativen Wert zurück. Allerdings greift dieselbe Logik auch für den Wert für "Erstellt von". Insofern funktioniert die Eigene Übersicht mit dieser Einschränkung auch ohne besondere Vorkehrungen für eine Anmeldung als Gastbenutzer.

►ANMERKUNG◄ Dass ein Gastbenutzer Konten für Benutzer erstellen kann, sollte normalerweise durch die Zuweisung einer geeignet eingeschränkten Rolle ausgeschlossen sein. Allerdings ist die Einschränkung in dieser Form für beliebige Entitäten einsetzbar.

Der Ribbon-Button (s. o.) löst ein Eigenes Aktionsevent "Mein Konto deaktivieren" aus, das als Auslösendes Ereignis für die rechts abgebildete Ereignisbehandlung gelistet ist.

Die Prüfende Regel soll hier ausdrücklich absichern, dass die unten gezeigte Ereignisaktionen nur ausgeführt werden, wenn als Benutzer der Session ein Gastbenutzer vorliegt.

Da der Ribbon-Button in unterschiedlichen Kontexten angeboten werden und nicht an die Auswahl eines bestimmten Bezugsobjekts gebunden werden soll, ist kein Eingabewert für das Ereignis zu erwarten. Insofern wäre eine direkte Typprüfung auf den Typ "Gastbenutzer" für den Eingabewert sinnlos.

Stattdessen wird die Typprüfung hier innerhalb einer Mit-Regel ausgeführt, für die der Benutzer der Session-Wertauflöser im Parameter Objekt Feld Resolver das Bezugsobjekt temporär verändert.

Auch wenn für dessen Rückgabewert formal der Typ "Schnittstelle > Benutzer" ausgewiesen wird (s. Bild) , liegt zur Laufzeit ein "Gastbenutzer"-Objekt vor, wenn Gastbenutzer angemeldet sind.

►ANMERKUNG◄ Im Unterschied zu einer direkten Typprüfung für den Eingabewert einer Ereignisbehandlung wird der in der Mit-Regel geprüfte Typ nicht als Kontext für die Aktion bei bestandener Regel angenommen. Stattdessen gilt der Kontext hier als unbestimmt ("Objekt").

Als Aktion bei bestandener Regel muss zunächst durch eine Ausführen als-Ereignisaktion ein Anmeldekontext mit geeigneten Zugriffsrechten (s. Als Rolle) hergestellt werden, da davon auszugehen ist, dass ein Gastbenutzer nicht berechtigt ist, Gastbenutzerkonten zu ändern.

• Wichtig ist dabei, dass für den optionalen Parameter Als Benutzer keine Auswahl getroffen wird, da dies den Bezug zum Benutzer der Session übersteuern würde, der durch die folgenden Aktionen bearbeitet werden soll.

• Damit der Schreibzugriff für das angemeldete Gastbenutzerkonto möglichst sicher gewährleistet ist, soll im Objekt Resolver der Ausführen mit-Ereignisaktion der aktuelle Datenstand dieses Kontos vom Server abgerufen werden. Dies ermöglicht die folgende Verkettung ausgehend vom Benutzer der Session-Wertauflöser:
  

  • Der Objekt-Feld-Wertauflöser liest das Feld "ID" (id) aus dem Rückgabewert für den Benutzer der Session.

  • Da die "Schnittstelle > Benutzer" für Gastbenutzer per Definition negative Long-Werte für die ID zurückgibt, muss der Berechne Wert-Wertauflöser hier das Vorzeichen "umdrehen", damit im folgenden Schritt der eigentlich positive Wert der ID als Eingabewert vorliegt.
    
    

  • Das zunächst als "Zahl mit Einheit" vorliegende Berechnungsergebnis muss im Anschluss über einen Eingabeobjekt (Typsicher)-Wertauflöser noch ausdrücklich als Long-Wert deklariert werden, bevor ein weiterer Eingabeobjekt (Typsicher)-Wertauflöser das betreffende Gastbenutzerkonto auflösen kann.

  • Mit dem so ermittelten Gastbenutzerkonto als Bezugsobjekt kann durch eine Setze Wert-Ereignisaktion dessen Feld "Aktiv" (active) der Wert false zugewiesen werden, bevor diese Änderung per Änderungen später speichern zum Speichern vorgemerkt wird.

Der dynamische Aufbau des Kontextmenüs erfolgt ausgehend von den Daten des Benutzer der Session (s. Parameter Objekt Resolver in der Ausführen mit-Ereignisaktion) in den rechts zunächst im Überblick dargestellten Schritten, die unterhalb im Detail beschrieben werden:

• Im ersten Schritt speichert eine Setze Wert-Ereignisaktion die Liste der eindeutigen Long-Werte, die Referenzen auf "relevante" Benutzer-/Gastbenutzerkonten sind, der Variablen accountIds zu.
  
  

• Im zweiten Schritt werden die Datenobjekte für die in der Variable accountIds aufgelisteten Konten vom Server abgefragt. Mit Hilfe der Ausführen als-Ereignisaktion wird das zu der Anmeldekontext so verändert, dass die für "Suche" erforderlichen Leserechte für Benutzer und Gastbenutzer gewährleistet sind. Die "gefundenen" Konten werden in zwei Listenvariablen (users und guests) übergeben.
  
  

• Im dritten Schritt werden innerhalb der Öffne Kontextmenü-Ereignisaktion die in den Listenvariablen (users und guests) getrennt je Entitätstyp abgefragten Konten zu einer gemeinsamen Liste vereinigt, die die Optionen für das Kontextmenü definiert.

Für den ersten Schritt wird eine Setze Wert-Ereignisaktion wie rechts abgebildet konfiguriert, um der Variablen accountIds (linke Seite der Zuweisung) die Liste der relevanten Konto-Referenzen zuzuweisen.

Auf der rechten Seite der Zuweisung wird die Liste durch eine Verkettung der folgenden Wertauflöser definiert:

• Der Erzeuge Liste-Wertauflöser wird hier verwendet, um aus den Werten der die drei relevanten Felder (id, creatorId und lastModifierId) aus dem Rückgabewert von Benutzer der Session ("Schnittstelle > Benutzer" im Kontext) eine Liste von Long-Werten zusammenzustellen. Der hierzu jeweils verwendete Objekt-Feld-Wertauflöser wurde im Bild zugunsten einer kompakteren Ansicht "zusammenklappt".
  
  

• Da die so zusammengestellte Liste noch Duplikate enthalten kann, wird sie im unterhalb verketteten Sammle Werte-Wertauflöser nachbearbeitet, da nur Eindeutige Werte zulässig sein sollen. Als Wert zum Sammeln wird dabei ein Eingabeobjekt (Typsicher)-Wertauflöser mit dem Typ "Long" verwendet, der darauf abzielt, dass der einzelne Eingangswert unverändert in die Liste übernommen wird (sofern noch nicht vorhanden).

Die Variable accountIds enthält zur Laufzeit aufgrund dieser Konfiguration eine Liste mit mindestens einem und maximal drei unterschiedlichen Long-Werten, die auf je ein Benutzer- oder Gastbenutzerkonto verweisen.

Positive Long-Werte verweisen dabei auf Benutzer und negative Werte auf Gastbenutzer.

Für den zweiten Schritt wird innerhalb einer geeignet parametrierten Ausführen als-Ereignisaktion zunächst ein geeigneter Anmeldekontext hergestellt, damit ausreichender Zugriff auf die Konten besteht, die gelesen werden sollen. Im Beispiel (im Bild nicht zu sehen) wird die Rolle "Super user" beansprucht. Damit besteht unabhängig von der Auswahl einer bestimmten "Firma" Vollzugriff auf alle Konten.

Der Abruf der Konten für das Kontextmenü per Suche (Ereignisaktion) muss in zwei Schritten erfolgen, da jeweils nur ein bestimmter Entitätstyp (Benutzer oder Gastbenutzer) vom Server abgefragt werden kann.

Das Bild rechts zeigt die Konfiguration für die Suche (Ereignisaktion) für die Entität Benutzer:

• Der Parameter Ergebnis speichern als definiert den Variablennamen users für den Rückgabewert.
  
  

• Mit dem Modus "Suchwert" wird der Variablen users eine Liste von Instanzen der Entität zugewiesen, wenn für den Parameter Suche die Option "Suche" ausgewählt ist.
  
  

• Die Bedingung prüft das Kriterium, dass der Wert der Feldprojektion für die "ID" (id) in der Liste der positiven Long-Werte in der Variablen accountIds enthalten ist. Der mit dem Variable-Wertauflöser verkette Regel-Listen Resolver gibt dabei Alle Werte als Liste zurück, die die Bedingung ">0" erfüllen.
  
  ►ANMERKUNG◄ Da es keine Benutzer-Konten mit negativen IDs gibt, könnte man auf die Einschränkung der accountIds auch verzichten. Dann würde ggf. die Vergleichsliste allerdings überflüssige Optionen enthalten.

Zur Laufzeit enthält die Variable users nach dem Ausführen der Suche (Ereignisaktion) eine Liste von Entitäten des Typs Benutzer, die auch leer sein kann, falls die Variable accountIds ausschließlich negative Werte enthält, die auf Gastbenutzer verweisen.

►HINWEIS◄ Die Suche (Ereignisaktion) "findet" nur Benutzer, die im anwendbaren Anmeldekontext auch gelesen werden können. Dieser hängt hier von der Parametrierung der umgebenden Ausführen als Ereignisaktion ab. Wird diese unpassend gewählt, "fehlen" ggf. relevante Benutzer als Adressaten im Kontextmenü.

Eine zweite Suche (Ereignisaktion), die die Entität Gastbenutzer betrifft definiert wiederum den Modus "Suchwert" und eine Suche vom Typ "Suche". Das Ergebnis ist eine Liste von Gastbenutzer-Konten, die in die Variable guests (nicht im Bild) geschrieben werden soll.

Die Bedingung für diese Suche (Ereignisaktion) verwendet die rechts dargestellte Konfiguration. Diese erfolgt analog zur Bedingung für die Benutzer (s. oben) mit den folgenden wichtigen Unterschieden:

• Der Regel-Listen Resolver (rechts im Bild) schränkt die Liste aus der Variablen accountsId diesmal auf negative Long-Werte ein, die als Referenzen auf Gastbenutzer interpretiert werden.
  
  

• Da die Feldprojektion für die "ID" der Gastbenutzer (links im Bild) ausschließlich positive Wert liefert, muss das Vorzeichen der negativen Vergleichswerte aus der Variablen accountIds umgekehrt werden. Dies ermöglicht der Berechne Wert-Wertauflöser, der zu diesem Zweck innerhalb eines verketteten Sammle Werte-Wertauflöser eingesetzt wird, um den Wert zum Sammeln zu definieren.
  
  

• Im Berechne Wert-Wertauflöser definiert die "Formel" -input die Vorzeichenumkehr für den Eingabewert (input).
  ►ANMERKUNG◄ Alternativ könnte hier auch die Formel abs(input)verwendet werden, um das Vorzeichen zu "eliminieren". Da der Regel-Listen Resolver ausschließlich negative Werte als Teilmenge aus den Werten in der Listenvariable accountIds liefert, macht das hier keinen Unterschied.
  
  

• Der unterhalb verkettete Eingabeobjekt (Typsicher)-Wertauflöser wandelt das Berechnungsergebnis ausdrücklich in einen Long-Wert um, damit dieser Datentyp für den Abgleich mit der Datenbank sichergestellt ist.

Zur Laufzeit enthält die Variable guests nach dem Ausführen der Suche (Ereignisaktion) eine Liste von Entitäten des Typs Gastbenutzer, die auch leer sein kann, falls die Variable accountIds ausschließlich positive Werte enthält, die auf Benutzer verweisen.

►HINWEIS◄ Die Suche (Ereignisaktion) "findet" nur Gastbenutzer, die im anwendbaren Anmeldekontext auch gelesen werden können. Dieser hängt hier von der Parametrierung der umgebenden Ausführen als Ereignisaktion ab. Wird diese unpassend gewählt, "fehlen" ggf. relevante Gastbenutzer als Adressaten im Kontextmenü.

Der dritte Schritt soll die in den Variablen users und guests gesammelten Konten zusammenführen und eine vereinigte Liste für Benutzer und Gastbenutzer zurückgeben.

Da diese Liste von Konten direkt die Auswahloptionen für das zu öffnende Kontextmenü definieren soll, kann diese Aufbereitung direkt in der Öffne Kontextmenü-Ereignisaktion untergebracht werden:

• Im Parameter Elemente werden die Listen aus den Variablen users und guests zunächst durch einen Erzeuge Liste-Wertauflöser als Liste von Listen (mit zwei Einträgen) zusammengefasst. Per Verkettung folgt unterhalb ein Sammle Werte-Wertauflöser, in dem die Option Listen vereinen gesetzt wird. Als Wert zum Sammeln wird ein Objekt-Feld-Wertauflöser ohne Feldauswahl verwendet, damit die Konten aus den beiden Quelllisten komplett als Einträge in die "vereinigte" Liste übergehen.
  
  

• Der Beschriftungsausdruck verkettet den Spracheintrag "Hinweis" ((common,info]) in Verbindung mit diversen Literalen mit Feldinhalten ({username}, {address.name1}) aus dem anzuzeigenden Konto, um die Beschriftung für den Kontextmenüeintrag aufzubauen.
  
  ►WICHTIG◄ Bzgl. {username} ist dabei zu berücksichtigen, dass der Aufbau des Kontextmenüs zur Laufzeit auch dann ein clientseitiger Lesezugriff (s. WICHTIG-Hinweis in der Einleitung) auf das jeweilige Konto gilt, wenn die Öffne Kontextmenü-Ereignisaktion innerhalb einer Ereignisbehandlung ausgeführt wird. Nur deshalb liefert der Zugriff auf das Feld username auch für Gastbenutzer nicht "kein Wert" (null), sondern den loginToken, während der Zugriff auf das Feld address.name1 für Gastbenutzer tatsächlich "kein Wert" (null) ergibt, so dass wie im Bild unten nur "leere Klammern" erscheinen:
  
  

  

  
  
  Der folgende Ausbauschritt illustriert mehr Details dazu.

An die bestehende Verkettung für den Parameter Elemente innerhalb der Öffne Kontextmenü-Ereignisaktion wird ein Liste sortieren-Wertauflöser angehängt, der das Feld username als Vergleichswert definiert.

• Durch die Verkettung mit einem In Großbuchstaben-Wertauflöser wird außerdem erreicht, dass beim Sortieren Großbuchstaben und Kleinbuchstaben "gleich behandelt" werden. Anderenfalls werden sonst Großbuchstaben vor Kleinbuchstaben einsortiert.

Laufzeitbeispiel:

• Das Sortierergebnis erscheint korrekt. Der im Bild hervorgehobene Gastbenutzer erscheint mit der führenden Ziffer "2" im username (alias loginToken) vor den Benutzerkonten, deren "Benutzername" ebenfalls aufsteigend sortiert erscheint. Das Gastbenutzerkonto im Beispiel wurde vom Benutzer Q erstellt von danach von QQQ geändert.

Allerdings trügt der Schein, wie eine weitere Stichprobe im Kontext eines anderen Gastbenutzers belegt:

Wie im letzten "Laufzeitbeispiel" (oben) zu sehen, greift die Sortierung zwischen mehreren Gastbenutzer-Einträgen im Kontextmenü mit der bisherigen Konfiguration nicht. Der mit der Ziffer "6" beginnende Eintrag müsste sonst an Position 2 erscheinen. Der Hintergrund:

• Obwohl der Aufbau des Kontextmenüs durch Öffne Kontextmenü clientseitig erfolgt, werden die Wertauflöser für die Elemente serverseitig verarbeitet, jedenfalls wenn die Ereignisaktion Teil einer Ereignisbehandlung ist, was im Kontext der Fall ist.

• Da das Liste sortieren serverseitig erfolgt, greift der Objekt-Feld-Wertauflöser für den username im Vergleichswert für Gastbenutzer ins leere. Der loginToken wird im Unterschied zum clientseitigen Zugriff nicht automatisch als Fallback zugeordnet. Damit lautet für alle Gastbenutzer der Vergleichswert "kein Wert" (bzw. "").

Die Konfiguration kann - z. B. wie rechts gezeigt - angepasst werden, um dieses Problem zu neutralisieren:

• Im Bild wurde der Objekt-Feld-Wertauflöser für den username ersetzt durch eine Textverkettung für die Felder username und loginToken. Da bei einem serverseitigen Lesezugriff auf ein Benutzer- oder Gastbenutzerkonto jeweils nur eines der beiden Felder einen Wert zurückgibt, ergibt die Textverkettung die "Vertretungsregelung" für den username, die clientseitig automatisch greift. Ergebnis: