Versionsinformationen

Neuheiten

  • Zugangskonzept: OE-Betreuer können eigene Dienstkonten administrieren und über Gruppenzuordnungen die Nutzung dieser Dienstkonten und die Administration der Dienst-Unterkonten für die Gruppenmitglieder freigeben.

  • Ergänzungen im Sudo-Feature bei der Transaktionsausführung

    • eigene Unterkonten können eingesetzt werden, dh. die Transaktion wird mit den Zugriffsrechten des eigenen Unterkontos ausgeführt.
    • Gruppenmitglieder können Dienstkonten einsetzen, dh. die Transaktion wird mit den Zugriffsrechten des Dienstkontos ausgeführt.
    • Abfrage des Transaktionsstatus/Modus
  • JSON-Schemavalidierung des Request Body (POST-Request). Das neue, gültige JSON-Schema ist im Versionsindex unter dem Schlüssel transaction_json_schema hinterlegt.

  • Erweiterte JOIN-Anweisungen für Ausgaben. Die bisherige JOIN-Anweisung join wird durch inner_join_ref ersetzt. Die neuen JOIN-Anweisungen lauten:

    • inner_join_ref
    • anti_join_ref
    • semi_join_noref
    • anti_join_noref.
  • Bedingte Ausführung von Transaktionsbefehlen (Statements) durch die WHEN-Anweisung

  • Wiederholte Ausführung von Transaktionsbefehlen (Statements) mit der Ref-Params-Anweisung

  • Neuer Objekttyp tmp.generic_object zur Erzeugung selbstdefinierter Objektdaten in Verbindung mit der Ref-Params-Anweisung sowie zu Testzwecken.

  • Neuer Objekttyp wapi.maint_state zur Abfrage des aktuellen Wartungsstatus oder geplanter Wartungen.

  • Generische Sprachunterstützung (Mehrsprachenfähigkeit)

    • automatische Formatierung der Sprachtexte im Eventlog und Exception-Handler enstprechend des Sprachparameters der Transaktion
    • Modellierung der Sprachinhalte (Sprachtexte) über die neuen Objekttypen cntl.ot_lang_attr_def, cntl.ot_lang_attr_val. Das Modellierungsprinzip ist analog zu den generischen Objektattributen cntl.ot_attr_def, cntl.ot_attr_val; ebenso die Abfragefunktionalität (als globale JOINs).
  • Geänderter Objekttyp cntl.data_type_operator:

    • Trennung zw. Datentyp und Operator, allgemeinere Abbildung
    • Operator-Unterstützung für globale Objektattributsuche in JSON-Daten

Die wichtigsten Änderungen bei Funktionen

  • Die Funktion dns.record.imp legt den FQDN automatisch an (falls nicht vorhanden) oder löscht ihn automatisch (falls nach dem Import leer und keine weiteren Konflikte entstehen). Der Parameter fqdn ist optional als Altwert und erforderlich als Neuwert verwendbar. Wird der Altwert angegeben, wird der alte FQDN, falls vorhanden, auf den Neuwert geändert. Diesem Fall darf der neue FQDN noch nicht vorhanden sein.

  • Die Funktionen create und update des Objekttyps dns.record haben bzgl. des FQDNs ein verändertes Verhalten:

    • der FQDN wird dabei nicht mehr automatisch erzeugt, sondern muss bereits vorhanden sein
    • die Attribute dns.record.fqdn_type und dns.record.fqdn_description entfallen deshalb auch bei dns.record.create
  • Die Funktionen update und delete des Objekttyps dns.fqdn bekommen das neue Boolean-Attribut try_del_parent (Standardwert: true). Übergeordnete FQDNs werden dadurch nach Verschieben oder Löschen des FQDNs automatisch mitgelöscht, wenn dabei kein Konflikt entsteht. Um den übergeordneten FQDN garantiert zu behalten, muss try_del_parent = false gesetzt werden.

  • Die Funktion dns.record.delete bekommt das neue Boolean-Attribut try_del_fqdn (Standardwert: true). Der FQDN wird dadurch nach Löschen des RRs automatisch mitgelöscht, wenn dabei kein Konflikt entsteht. Um den FQDN garantiert zu behalten, muss try_del_fqdn = false gesetzt werden.

  • Die Funktionen create, update, delete des Objekttyps dns.fqdn wirken jetzt automatisch-rekursiv, wenn der FQDN das Attribut is_nonterminal = true hat. Wird ein FQDN erzeugt, dessen Parent-FQDN ebenfalls nicht existiert, so wird der Parent-FQDN (einschließlich aller weiteren darüberliegenden, nicht vorhandenen Parent-FQDNs) automatisch mit gleichem FQDN-Typ erzeugt, solange keine Konflikte entstehen. Beim Löschen ist die Wirkung umgekehrt analog, dh. alle weiteren darüberliegenden FQDNs werden automatisch mitgelöscht, solange keine Konflikte entstehen. Der Automatismus endet stillschweigend in der FQDN-Ebene, wo ein Konflikt entstehen würde. Beim Verschieben des FQDNs werden analog die ggf. fehlenden neuen Parent-FQDNs erzeugt und die ggf. verbleibenden alten Parent-FQDNs gelöscht. Diese automatische Löschung kann durch Setzen des Attributs try_del_parent = false verhindert werden.