Angenommen, Sie möchten den Wert eines Feldes abhängig von der Benutzerrolle einschränken oder Sie möchten innerhalb einer Relation zu anderen Collections auf ein Feld des Parent-Items filtern. Directus bietet derzeit keine direkte Möglichkeit an, dies umzusetzen.

Als Beispiel dient folgende Veranschaulichung: Sie haben eine Collection “Spesengesuche” und eine 1:n Relation zur Collection “Sitzungen”. In “Spesengesuch” ist das Feld “Nur Sitzungen länger als 4h” ausgewählt. In “Sitzung” wird die Dauer der Sitzung festgehalten. So erlaubt es Directus nicht, die Sitzungen im entsprechenden Auswahldialog der Relation dynamisch nach der Sitzungsdauer bei Aktivierung “Nur Sitzungen länger als 4h” zu filtern.

Das bedeutet, dass Benutzer potenziell alle Sitzungen, auch Sitzungen kürzer als 4 Stunden, hinzufügen können – ein klarer Fall, bei dem spezifischere Validierungsregeln benötigt werden.

Ein kreativer Workaround

Bei der Implementierung des oben geschilderten Szenarios stösst man auf die Einschränkung, dass man in Directus beim Hinzufügen von relationalen Elementen nicht auf Werte des Hauptelements (z. B. per $this) zugreifen kann.

Die gute Nachricht ist, dass es für dieses Problem einen praktischen Workaround gibt. Dieser Ansatz nutzt die Flexibilität von Directus, um mit einem Event Hook und einem Custom Script eine Validierung zu implementieren:

1. Einrichtung eines Event-Hooks: Erstellen Sie einen Flow als Event-Hook vom Typ “Filter (Blocking)”, der auf item.create oder item.update Ereignisse hört.
2. Validierung durch ein “Run Script”: Im Rahmen dieses Hooks können Sie ein Skript ausführen, das eine Validierung durchführt. Wenn die Validierung fehlschlägt, kann das Skript einen Fehler werfen, welches ein Alert generiert:

   throw {message: "Sie dürfen nur Sitzungen länger als 4h auswählen.")

Zum aktuellen Zeitpunkt kann diese Fehlermeldung per “Run Script” aber nur für Admin-User gelesen werden, für alle anderen Rollen erscheint eine Standard-Fehlermeldung. Damit zukünftig alle Rollen die Fehlermeldung lesen können, ist bereits ein Feature-Request bei Directus bestätigt worden https://github.com/directus/directus/discussions/18634

Der Workaround, um für alle Benutzer die Fehlermeldung anzuzeigen, ist eine eigene Error-Operation als Directus-Extension. Im Handler dieser Operation kann mit createError eine eigene Fehlermeldung ausgegeben werden:

import {createError} from '@directus/errors';

const Error = createError("FORBIDDEN", "Sie dürfen nur Sitzungen länger als 4h auswählen.", 403);
throw new Error();

Diese Methode erlaubt es, praktisch jede Art von Validierungslogik umzusetzen – zum Beispiel die Einschränkung, dass nur Sitzungen länger als 4 Stunden zum Spesengesuch hinzugefügt werden können.

Die Grenzen von Directus und das Potenzial für Verbesserungen

Trotz der Stärken von Directus zeigt dieses Beispiel, dass es bei der Implementierung von Validierungs- und Filterungslogiken noch Verbesserungsbedarf gibt. Aktuell sind die Möglichkeiten ohne Custom Scripts oder Hooks eher begrenzt. Insbesondere fehlt die Möglichkeit, einfach benutzerdefinierte Validierungsregeln mit JavaScript direkt unter Conditions oder Validations zu hinterlegen.

Fazit

Während Directus eine mächtige Plattform für die Content-Verwaltung ist, stösst man bei spezifischen Validierungs- und Filterungsanforderungen gelegentlich an Grenzen. Der beschriebene Workaround bietet jedoch einen kreativen Weg, um diese Herausforderungen zu meistern, und zeigt, wie flexibel und anpassbar Directus trotz allem ist. Es bleibt zu hoffen, dass zukünftige Updates von Directus es ermöglichen werden, solche Anforderungen direkt und ohne Umwege zu erfüllen. Bis dahin eröffnet die Community und die Möglichkeit, eigene Hooks und Scripts zu implementieren, einen Raum für kreative Lösungen.