FeatureAb VersionWo (Einstellung)Wie (Beispiel)Beschreibung / Hinweise

Beeinflussung des Lokalen Nuclet Identifierers

Migration 3.x -> 4.0

4.0Irgendwo in Beschreibung des Nuclet

migration_04_00_00.nuclet.preferred.local.identifier=C3PO

Ein Lokaler Identifizierer besteht immer aus 4 Zeichen, im Beispiel "C3PO", sollte sich nur aus A-Z0-9_ zusammensetzen und mit einem Großbuchstaben beginnen. "T_EO" wäre also auch noch möglich!

Nur die Migration 3.x -> 4.0 wird den Identifizierer aus der Beschreibung lesen, im Anschluss kann dieser gelöscht werden.

Sollten mehrere Nuclets den gleichen Identifizierer fordern (ist nicht sichergestellt -> "preferred") wird nur eines der Nuclets diesen bekommen, alle anderen bekommen dann einen Zufälligen.

Beeinflussung des Lokalen Nuclet Identifierers

Nuclet Import

4.0T_AD_APPLICATION. STRLOCALIDENTIFIER
  1. .nuclet Datei entpacken (z.B. vorher in .zip umbenennen) und Inhalte bis auf die Nuclets entfernen:
  2. Nuclet "Hülle" importieren -> Ein neuer lokaler Identifiezierer wird vergeben
  3. In der Datenbank den lokalen Identifizierer ändern (T_AD_APPLICATION.STRLOCALIDENTIFIER) 
  4. Das echte Nuclet importieren -> Eingestellter lokaler Identifizierer wird verwendet

So wird es möglich, den Identifizierer noch vor der ersten Verwendung zu beeinflussen.

Für die Zukunft ist ein Hidden Feature direkt im Nuclet Import geplant.

Aber das sollte immer nur die Ausnahme bleiben! Im Regelfall und für den Betrieb einer Standard Multinuclet-Umgebung muss ein Nuclet mit einem zufälligen LI umgehen können!


File Encoding der Java VM nachträglich auf UTF-8 umstellen4.0nuclos.xml

<nuclos>
<server>
...
<force-file-encoding-utf8>true</force-file-encoding-utf8>
</server>

...

Ab Nuclos 4.0 werden neue Instanzen nur noch mit dem UTF-8 File Encoding betrieben, falls das nicht schon durch das Betriebssystem als Default gesetzt wird. Wenn man eine ältere Instanz auf Nuclos 4.0 aktualisiert wird das Default Encoding beibehalten. Möchte man diese ebenfalls auf UTF-8 ändern, so muss man in der nuclos.xml den Parameter auf >true< setzen und den Installer erneut Ausführen.

Betroffen werden hauptsächlich Windows und Mac OS X Server sein. Unter Linux ist häufig UTF-8 bereits das Default Encoding.

Sollte sich durch diesen Parameter das Encoding ändern können die Passwörter von Benutzern nicht mehr überprüft werden und müssen über die Datenbank zurückgesetzt werden!

Report & Formular Vorlagen könnten ebenfalls betroffen sein.


Downgrade einer Datenbank4.0server.propertiesautosetup.version.check.enabled=false

Hiermit wird die Validierung "Found schema is newer..." ausgeschaltet, und das Autosetup wird einen Downgrade starten, falls eine frühere Nuclos Version mit dem Schema gestartet wird.

Ein Downgrade funktioniert nicht immer! Zum Beispiel wenn mit einer neueren Version eine NOT NULL Spalte gelöscht wird. Diese kann ein Downgrade nur anlegen wenn die Tabelle noch keine Daten enthält. Auch können weitere Inhalte der Konfiguration gegen einen Downgrade sprechen. Zum Beispiel wenn ein Layout schon Komponenten enthält, die eine frühere Version nicht kennen kann, usw.

Migrationen können ebenfalls nicht zurückgerollt werden!


Datenbank Schema Validierung beim Serverstart4.2server.properties

autosetup.validate.schema.enabled=true

Löscht vorhandene Contraints, führt eine Schema Validierung durch und legt im Anschluss alle Constraints wieder an.
SVG Ausführbar im Webclient4.50BO-Attribute Benennung muss mit "isexecutable" enden und vom Typ Grafik seingrafik_isexecutable - Grafik

Dies weist den Webclient an das Bild direkt per SVG/XML zu rendern und enthaltene JavaScript Anweisungen in den HEAD zu transportieren. 

Sollte das SVG JavaScript enthalten, wird dies direkt im Browser ausgeführt wenn es angezeigt werden soll. Dies kann zu potentiellen XSS Sicherheitslücken führen und sollte nur unter äußerst sicheren Bedingungen erwogen werden.