Während für ein normales Kommando auf einem Modell eine Kommandogruppe festgelegt werden kann, fehlt ein vergleichbares Konzept für Drag&Drop-Operationen. Da diese Operationen auch Änderungen durchführen können, muss sichergestellt werden, dass der Nutzer die Berechtigung hat, diese Änderung durchzuführen. Auch muss berücksichtigt werden, ob der Befehlsfreigabedienst die Ausführung einer Drag&Drop-Operation verhindern sollte.

Ausgangslage

Ein Kommando wird vor der Ausführung (und für die Anzeige als ausführbar/deaktiviert) in dieser Reihenfolge geprüft: Befehlsfreigabedienst (CommandApprovalService), Zulässigkeit der Kommandogruppe für den Nutzer (z.B. eingeschränktes Benutzerkonto), Rechte des Nutzers für die Kommandogruppe auf dem Sicherheitsobjekt. In-App konfigurierte Drops in Tabellen, Grids, Bäumen, Baum-Tabellen und im Flow-Diagramm führten ihr Drop-Skript dagegen ohne jede dieser Prüfungen aus.

Lösung

• Die Prüfsequenz von Kommandos (Befehlsfreigabe → Gruppe für Nutzer zulässig → Rechte auf dem Sicherheitsobjekt) steht als CommandSecurity.checkSecurity(...) zur Verfügung; CommandDispatcher und die Drops verwenden sie gleichermaßen.
• In-App konfigurierte Drops (TableDropTargetByExpression, GridDropTargetByExpression, TreeDropTargetByExpression, TreeTableDropTargetByExpression, OntoTreeDropByExpression, OrderedTreeDropByExpression sowie der Flow-Diagramm-Drop ScriptedDropHandler) haben die neuen Optionen (DropSecurityConfig):
  • Gruppe (group, Vorgabe: Write).
  • Ziel (target): TL-Script-Funktion mit denselben Argumenten wie die Drop-Prüfung (beim Flow-Diagramm: wie das Drop-Skript), die das Zielobjekt der Prüfung liefert. Ohne Angabe ist das Ziel die Zeile, auf die gezogen wird (Tabelle), das Fachobjekt des Zielknotens (Baum), das Fachobjekt des Elternknotens, in den eingefügt wird (geordneter Baum-Drop), bzw. das Fachobjekt des Diagrammelements, auf das gezogen wird (Flow-Diagramm). Ein technischer Baumknoten ist nie Zielobjekt, geprüft wird immer sein Fachobjekt. Ist das Ziel leer, wird das Modell der Komponente geprüft.
• Wie bei Kommandos bestimmt die Sicherheitskonfiguration der Komponente aus dem Zielobjekt das Sicherheitsobjekt, auf dem die Rechte geprüft werden (z.B. das Rollenprofil der Sicht).
• Ein Drop, den die Prüfung ablehnt, wird beim Überfahren nicht als möglich angezeigt; ein trotzdem ausgelöster Drop wird serverseitig vor der Ausführung des Drop-Skripts abgewiesen. Das gilt auch für aufgezeichnete Drops in Skript-Tests.
• Selbst implementierte Drop-Targets in Java können dieselbe Prüfung (CommandSecurity, DropSecurity) verwenden; sie werden nicht automatisch geprüft.

Test

• test.com.top_logic.model.search.providers.TestScriptedDropSecurity, test.com.top_logic.graphic.flow.server.ui.handler.TestScriptedDropHandlerSecurity.
• tl-demo: Technisches Demo > Layout-Framework#1 > Formulare > In-App Drag and Drop: Als root funktionieren die Drops in Baum und Tabelle wie bisher. Ein Benutzer, der im Rollenprofil dieser Sicht nur Lesen (nicht Ändern) hat oder ein eingeschränktes Benutzerkonto besitzt, bekommt beim Ziehen keine Drop-Markierung, und der Drop ändert nichts.

Migration

In-App konfigurierte Drops werden nun mit der Kommandogruppe Write auf dem Ziel des Drops geprüft. Nutzer ohne Schreibrecht (bzw. bei Ablehnung durch den Befehlsfreigabedienst oder mit eingeschränktem Benutzerkonto) können solche Drops nicht mehr ausführen. Soll ein Drop mit einer anderen Berechtigung erlaubt sein, muss in der Drop-Konfiguration eine passende Gruppe (group) bzw. ein passendes Ziel (target) angegeben werden.