Aktionen als Reaktion auf Ereignisse oder als Wiedervorlage / Erinnerung

• » Home
• »Server-Daten
• »Menü-Hilfe
• » Aktionen

Zu jeder benutzerdefinierten Tabelle sowie zu allen Systemobjekten können Aktionen definiert werden. Bei Aktionen gibt es zwei grundsätzliche Typen: Entweder reagieren sie auf Datenänderungen wie dem Hinzufügen, Ändern oder Löschen von Zeilen und versenden innerhalb von wenigen Minuten nach einem solchen Ereignis eine Mail. Oder sie werden mit einer benutzerdefinierten Datumsspalte verknüpft und benachrichtigen per Mail, falls der Wert einer Datumsspalte von einem Datensatz mit dem heutigen Datum übereinstimmt. Damit steht die Funktion einer Wiedervorlage zur Verfügung. Zusätzlich läßt sich eine positive oder negative Differenz in Tagen, Wochen oder Monaten angeben, so daß bsp. ein Datum 01. März 2006 zu einer Benachrichtigung am gleichen Tag oder am 05. Mai 2006 führt.

Suchen

Neue Aktion

Speichern

Abbruch

---

Hilfe

Übersicht  (1/1) ≪ < 1 > ≫  -    Nutzerbearbeitung

Id ↑↓ Name der Aktion * ↑↓ Tabelle ArtikelUmsatzVertreterAbfragenAktionenMultilang-SpaltenDownload von TabellenEinschränkungenIndicesNutzer- und GruppenrechteSystemnutzer↑↓ Ereignis * AllInsertUpdateDelete↑↓ Datumsspalte ---Umsatz.Datum↑↓ Datums-Einheit (1) * daysweeksmonths↑↓ Tage / Wochen / Monate (1) ↑↓ Datums-Einheit (2) ---daysweeksmonths↑↓ Tage / Wochen / Monate (2) ↑↓ Optionen der Aktion ---Mail with Dataupdate Rowremove Row↑↓ Update-Spalte ---↑↓ Update-Ausdruck ↑↓ Zustand der Aktion * activeinactive↑↓ Owner adminserver-daten

Die Benachrichtigung bei neuen / geänderten / gelöschten Datensätzen wird durch die zwei Einträge Tabelle / Ereignis definiert. Die Einträge von 'Datumsspalte' bis 'Tage / Wochen / Monate (2)' ermöglichen eine Erinnerung / Terminverfolgung / Wiedervorlage.

• Name der Aktion: Der Name dient nur dazu, diese Aktion in der Ergebnisliste von anderen Aktionen zu unterscheiden. Ansonsten wird der Name nicht weiter verwendet.
• Tabelle: Hier werden zunächst die benutzerdefinierten Tabellen gelistet, anschließend folgen die Systemereignisse. Sie entsprechen im wesentlichen den Standardmenüs.
• Ereignis: Ermöglicht die Festlegung, ob nur auf ein einzelnes (Insert/Update/Delete-) Ereignis oder auf alle Ereignisse reagiert werden soll.
• Datumsspalte: Hier ist eine der Spalten vom Datentyp 'dateTime' auszuwählen, falls eine Erinnerung / Wiedervorlage erzeugt werden soll.
• Datums-Einheit (1): Hier wird die Einheit festgelegt, nach welcher der Wert in der folgenden Spalte interpretiert wird.
• Tage / Wochen / Monate (1): Dieses Feld ist mit einer Ganzzahl (positiv oder negativ) zu füllen. Eine Wahl 'days' im Feld darüber und '5' für dieses Feld erzeugt eine Erinnerung nach 5 Tagen.
• Datums-Einheit (2): Sind dieses und das nächste Feld belegt, so werden zum Datum, das sich aus den beiden (1) - Einträgen ergibt, weitere Tage/Wochen/Monate hinzugefügt bzw. abgezogen. Diese Verdoppelung wurde eingefügt, um bsp. folgendes zu ermöglichen:

  Datums-Einheit (1): months
  Tage / Wochen / Monate (1): 3
  Datums-Einheit (2): days
  Tage / Wochen / Monate (1): -5

  Hat ein Datumsfeld den Wert 01.03.2006, so erfolgt die Benachrichtigung am 27.05.2006, also drei Monate voraus und von dort wieder 5 Tage zurück.

  Damit ist es möglich, bei Terminen, die bsp. in sechs Monaten wichtig werden, knapp zuvor eine Erinnerung zu erhalten, ohne daß komplizierte Rechnungen, Komma-Zahlen oder eine zu frühe Wiedervorlage (Nachricht nach 5 Monaten) erzeugt werden.

• Optionen der Aktion: Für eine Benachrichtigung bei Datenänderungen oder beim Erreichen eines bestimmten Zeitpunkts muß hier die Option 'Mail with data' gewählt werden. Sind eine Datumsspalte und Datumseinheiten, eine Update-Spalte und ein Update-Ausdruck gewählt, so löst die Option 'update Row' das Aktualisieren der Zelle zum angegebenen Tag (derzeit nachts gegen 02:30) aus. Wird als Option 'remove Row' gewählt, so wird die Zeile, die den per Datumsspalte und Datumseinheiten definierten Zeitpunkt erreicht hat, gelöscht (ebenfalls nachts um 02:30).

  Berechtigung: Für Update- und Remove-Aktionen muß der Besitzer der Aktion StvAdmin oder Administrator für diese Tabelle sein. Zum Ausführungszeitpunkt wird zusätzlich geprüft, ob er das Recht hat, auf die internen Menüs zuzugreifen. Es genügt nicht, daß der Nutzer nur Zeilen zu dieser Tabelle hinzufügen, ändern oder löschen kann. Diese Berechtigungen werden nicht beim Erstellen der Aktion, sondern immer nur bei der nächtlichen Ausführung überprüft.

• Update-Spalte: Falls eine Datumsspalte und Datumseinheiten gewählt wurde, wird diese Pulldown-Liste mit den Spalten derselben Tabelle bestückt. Beim Erreichen dieses Datums und der Aktionsoption 'Update' wird die hier festgelegte Spalte aktualisiert.
• Update-Ausdruck: Mit dem hier festgelegten Ausdruck wird die Update-Spalte neu belegt. Der Ausdruck kann eine Konstante (1, '1', 'ABC') oder eine Verknüpfung aus Spaltennamen der Update-Tabelle, Konstanten und Operatoren sein. Nutzer mögen bsp. neue Anzeigen in einer Ausgabeseite eintragen, die zunächst auf den Status 1 gesetzt werden. Nach sieben Tagen sollen diese Anzeigen nicht mehr sichtbar sein, also werden sie per Update auf '2' gesetzt.

  Beispiel für eine Operation: Es werde die Spalte 'Status' aktualisiert:

  Status + 1

  Dies erhöht den Wert in der Spalte 'Status' um 1.

  Es sind alle Ausdrücke zulässig, die innerhalb einer Sql-Abfrage eine Spalte ausgeben.

• Zustand der Aktion: Dieses Feld ermöglicht die Deaktivierung einer Aktion, so daß sie nicht mehr ausgeführt wird. Dies kann nützlich sein, falls Benachrichtigungen unterbrochen werden sollen, die Aktion für später jedoch noch benötigt wird.

Hinweise

Zur Erstellung einer eigenen Aktion genügt es, das Add-Recht für Aktionen zu besitzen. Die Berechtigung, ob auf die gewünschte Tabelle zugegriffen werden darf, erfolgt nicht zu diesem Zeitpunkt. Nach dem Erstellen oder Bearbeiten prüft der Datenbankserver, ob für die gewählte Tabelle bereits Aktionen dieses Ereignis-Typs definiert wurden. Falls notwendig, werden die Standardprozeduren zu dieser Tabelle neu erstellt und um Code ergänzt, der den aktuellen Datensatz, Besitzer und letzten Bearbeiter in eine zentrale Tabelle kopiert. Der Webserver überprüft diese Tabelle derzeit alle 5 Minuten. Für den Erhalt einer Mail ist das Leserecht auf der in der Aktion angegebenen Tabelle notwendig. Der Webserver ermittelt die berechtigten Empfänger, faßt mehrere Benachrichtigungen an einen Empfänger zu einer Mail zusammen und versendet diese. Der Nutzer, der durch seine Bearbeitung die Aktion ausgelöst hat, erhält keine Mail.

Die Wiedervorlagen werden immer einzeln versendet, so daß einem erreichten Termin eine Mail entspricht. Der Datenbankserver überprüft einmal pro Tag (derzeit gegen 02:30), ob Wiedervorlagen gewünscht sind. Diese Mails werden folglich immer nachts verschickt. Die Berechtigung zum Lesezugriff auf die Tabelle wird direkt vor dem Versenden der Mail geprüft.

Keine Übertragung der Berechtigung: Für Aktionen ist charakteristisch, daß ein Nutzer eine Aktion immer nur für sich selbst erstellen kann und er das Ausführungsrecht nicht an einen anderen Nutzer weitergeben kann, so daß dieser Benachrichtungen erhält. Denn jede aktive Aktion erzeugt Mailverkehr. Es ist jedoch innerhalb des Gesamtsystems zwingend, daß die Entscheidung, ob Mails an eine gewisse Adresse gesandt werden, vom Besitzer dieser Mailadresse entschieden wird. Eine Delegationsmöglichkeit für Aktionen würde diesem Prinzip widersprechen. Aktionen werden deshalb nicht einzeln unter <Objekt> im Menü 16 / Erstellen von Berechtigungssätzen aufgeführt.

Mailcodierung: Wird bei einer Aktion die Option 'Mail with Data' gewählt und enthalten die Daten Unicode-Zeichen, so kann es in Abhängigkeit vom genutzten Mailprogramm zu Problemen bei der korrekten Darstellung der Mail kommen. Unter 'Eigene Daten - Einstellungen' können alternative Optionen festgelegt werden. Hier muß der Nutzer verschiedene Varianten testen. Es ist auch denkbar, daß das Mailprogramm zu wenige Varianten unterstützt und Daten damit nicht lesbar sind.

Umgang mit ungültig gewordenen Mailadressen: Jede Mail bei Datenoperationen enthält einen Anhang, der ungefähr wie folgt aussehen kann:

--------------------------------
<www.server-daten.de><mail-info db-name='test' Id='3'>
RgA2ADcAOAAxAEIAMABGAC0AQgBFADIANAAtADQANgA0ADgALQA5ADkANgBCA
C0AMQAwADAANwAyAEIAQwA0AEQAMQBEADQA
</mail-info></www.server-daten.de>

Hierbei handelt es sich um die Base64-Codierung eines zufällig generierten Schlüssels, welcher der Mailadresse beim Erstanmelden des Nutzers hinzugefügt wurde. Falls die Mailadresse in der Zwischenzeit ungültig geworden ist, so wird - aufgrund des Standard-Mailhandlings - die Mail an server-daten zurückgesandt. Alle an dieses Mailkonto eingehenden Mails werden per Programm überprüft, ob es sich bei ihnen (1) um einen Mail-Report (ungültige Domain, ungültiger Nutzername) mit einem gültigen Delivery-Status handelt, (2) ob der Report von server-daten erzeugt wurde und ob (3) in der angegebenen Datenbank dieser Nutzer-Id bzw. der Mailadresse der angegebene Schlüssel zugeordnet werden kann. Falls ja, so wird die Mailadresse als ungültig betrachtet und gesperrt, sie wird anschließend für Aktionen nicht mehr berücksichtigt. Die Sperrung ist im Menü 'Nutzer' sichtbar.

Der Sinn des zufällig erzeugten Schlüssels besteht darin, das zwar aufwendige, aber prinzipiell mögliche Fälschen eines Delivery-Reports, welcher an die server-daten-Mailadresse gesendet werden würde und aufgrund des obigen Mechanismus zur Sperrung der Mailadresse führen würde, zu erschweren. Falls es sich um ein temporäres Problem mit diesem Mailserver handelt, kann der Nutzer seine (alte oder neue) Mailadresse im Menü 'Eigene Daten - Sicherheit' als neue Mailadresse eintragen. Er erhält daraufhin eine Standardmail mit einem Schlüssel, der zu bestätigen ist.