Änderungen von Dokument FORMCYCLE 7.0.0

Von Version < 39.1 >

bearbeitet von Release Notes
am 24.08.2021, 14:02

Auf Version < 40.1

bearbeitet von Release Notes
am 24.08.2021, 14:06

Änderungskommentar: Es gibt keinen Kommentar für diese Version

Rohform
Im Layout

Zusammenfassung

Objekte (1 geändert, 0 hinzugefügt, 0 gelöscht)
- Blog.BlogPostClass[0]

Details

Blog.BlogPostClass[0]

image

...	...	@@ -1,1 +1,0 @@
1		-comming_soon.png

Kategorie

@@ -1,1
          +1,1 @@
--Blog.News, Blog.Preview
++Blog.News, Blog.Release Note

Inhalt

@@ -1,246
          +1,7 @@
  {{localize language="de"}}
  Alle Informationen zu dieser und allen künftigen Versionen befinden sich in der neuen Hilfe zur Version 7: [[https://help7.formcycle.eu/xwiki/bin/view/Blog/>>https://help7.formcycle.eu/xwiki/bin/view/Blog/]]
--
--{{info}}{{formcycle/}} benötigt ab Version 7.0.0 **Java 11+**. Java 15/16/17 werden noch nicht unterstützt.{{/info}}
--
--{{info}}Bitte überprüfen Sie vor einer Aktualisierung, ob alle von Ihnen benötigten Plugins bereits für Version 7.0.0 verfügbar sind. Diese finden Sie wie immer in Ihrem Download-Bereich unter [[customer.formcycle.eu>>https://customer.formcycle.eu]].{{/info}}
--
--{{info}}Für den Betrieb von {{formcycle/}} ab Version 7.0.0 muss eine aktualisierte Lizenz ausgestellt werden.{{/info}}
--
--{{info}}Bisher waren //WebSockets// optional. Ab Version 7.0.0 sind diese allerdings zwingend notwendig. Um die korrekte Funktionalität zu gewährleisten, sollte geprüft werden, dass WebSockets entsprechend ermöglicht werden. Hier müssen gegebenenfalls entsprechende Ports freigegeben werden.{{/info}}
--
--{{info}}Falls eine eigene Protocol-Stack-Konfigurationsdatei für das {{formcycle/}}-Cluster (cluster.properties, Eintrag cluster.protocol.file) verwendet wird, muss diese geprüft werden. JGroups wurde auf Version 5 aktualisiert. Einige veraltete Protokolle sind nicht mehr verfügbar und einige Einstellungen können sich geändert haben. Siehe hierzu auch die [[Dokumentation von JGroups>>http://www.jgroups.org/manual5/index.html]]{{/info}}
--
--=== Der neue Workflowdesigner ===
--
--(% style="text-align:center" %)
--[[image:feature_workflow_designer_de.png||height="400"]]
--
--Der neue //Workflowdesigner// ermöglicht es, die Verarbeitung von Formularen auf eine intuitive und visuelle Weise per Drag & Drop zu erstellen. Die Verarbeitung wird nun über ein ereignisbasiertes Flussdiagramm dargestellt. Einzelne Verarbeitungsketten werden von Ereignissen ausgelöst. Ereignisse sind etwa der Klick auf einen Absendeknopf, das Bestätigen eines Double-Opt-In-Vorgangs oder die Überschreitung eines definierten Zeitpunktes. Bedingungen innerhalb dieser Verarbeitungsketten werden visuell durch Abzweigungen im Diagram dargestellt. Dieser neue Workflowdesigner stellt die Grundlage für die zukünftige Formularverarbeitung in {{formcycle/}} dar und wird mit kommenden Updates durch weitere Ereignis- und Aktionstypen erweitert. Die alte [[Status- und Aktionsverarbeitung>>doc:Formcycle.UserInterface.MyForms.WorkflowProcessing.WebHome]] wird nicht aktiv weiterentwickelt.
--
--=== Weitere Features ===
--
--; W3C konformer Modus
--: Die neue Formulareigenschaft //W3C konformer Modus// sorgt dafür, dass das durch das Formular erzeugte HTML wohlgeformt und gemäß der W3C-Spezifikation [[W3C>>https://www.w3.org/]] valide ist. Dieser Modus ist für alle neuen Formulare aktiviert und für bereits bestehende Formulare deaktiviert. Bei aktiviertem W3C-Modus stehen einige Attribute an den HTML-Elementen nicht mehr zur Verfügung, wie etwa //cn=// und //xn=//. Im JavaScript und CSS sollten daher die Selektoren //[data-cn=...]//, //[data-name=...]//, //[data-xn=...]// etc. verwendet werden. Die neuen //data//-Attribute werden sowohl bei aktiven als auch deaktivierten W3C-Modus an die Formularelemente geschrieben.
--
--; Validierung des Absendebuttons
--: Es gibt die neue Formulareigenschaft //Absendebutton validieren// im Designer. Wenn aktiviert, wird geprüft, ob es den Absendebutton zum Zeitpunkt der Auslieferung des Formulars wirklich gab.
--
--; Formularelement-Refactoring
--: Wenn Formularelemente umbenannt werden, funktionieren möglicherweise Teile des JavaScript oder der Verarbeitung nicht mehr korrekt, da diese das Formularelement über dessen Namen referenzieren. Mit dem //Formularelement-Refactoring// können Formularelemente umbenannt werden, wobei sämtliche Referenzen auf dieses Formularelement automatisch angepasst werden.
--
--; Zähler
--: Es gibt eine neue //Zähler//-Komponente zum Anlegen von Zählern inklusive einer neuen //Workflow-Aktion// zum Ändern des Zählerwerts und Zugriff auf den Zählerwert über Platzhalter und URL.
--
--; Neue Workflow-Aktion //Server-Attribut setzen//
--: Über die neue Workflow-Aktion //Server-Attribut setzen// können Attribute an einem Vorgang hinterlegt werden und diese über einen Platzhalter ausgelesen werden.
--
--; Neue Workflow-Aktion //LDAP-Abfrage//
--: Mit der neuen Workflow-Aktion //LDAP-Abfrage// können im neuen Workflow LDAP-Abfragen getätigt und die Ergebnisse weiterverarbeitet werden.
--
--; Zusätzliche Header in der Aktion //POST-Request//
--: In der neuen Workflow-Aktion //POST-Request// können zusätzliche Request-Header konfiguriert werden.
--
--; Verarbeitung von Vorgangsanhängen
--: Im neuen Workflow kann in den Aktionen //E-Mail// & //Speichern im Dateisystem// auf Vorgangsanhänge zugegriffen werden. Diese Dateien können als Anhang in E-Mails verwendet beziehungsweise im Dateisystem gespeichert werden.
--
--; Loginschutz pro Status
--: Im neuen Workflow kann, analog zum initialen Aufruf eines Formulars, pro Status konfiguriert werden, welche Anmeldemöglichkeiten für Vorgänge in diesem Status zur Verfügung stehen.
--
--; Neuer Externer Benutzer: //OAuth 2.0//
--: Es können nun auch externe Benutzer für das Authorisierungprotokoll//OAuth 2.0// angelegt werden.
--
--; Kontextsensitve Parameter für Logging-Pattern
--: [[Logging>>doc:Formcycle.SystemSettings.UserInterface.Logging.WebHome]]-Pattern können um kontextsensitive Parameter erweitert werden, um detaillierte Log-Ausschriften zu erhalten.
--
--=== Changes ===
--
--* Gesperrte Vorgänge können im Postfach mit der entsprechenden Berechtigung entsperrt werden.
--* Initialisierte Double-Opt-In-Vorgänge können im Postfach mit der entsprechenden Berechtigung überprüft und Double-Opt-In-Nachrichten erneut gesendet werden.
--* Geplante Aktionen werden im Verlauf eines Vorgangs im Postfach angezeigt.
--* Es gibt nun ein separates Rollenrecht für das Ändern der Formularversion eines Vorgangs im Posteingang.
--* In der neuen Workflow-Aktion //Weiterleitung// kann nun auch direkt eine URL eingegeben werden.
--* In den Formulareigenschaften des Designers kann ausgewählt werden, dass jedem Formularelement eine CSS-Klasse mit deren Namen hinzugefügt wird. Diese Option ist standardmäßig für neue Formulare aktiviert.
--* Die enthaltenen Plugins werden auch angezeigt, wenn das Plugin-Bundle deaktiviert ist.
--* Das HTML-Template //Systeminformationen// wurde als veraltet markiert und sollte nicht mehr verwendet werden.
--* Der Kompatibilitätsmodus beim Formularexport wurde entfernt. Formulare mit neuem Workflow können nur in {{formcycle/}}-Installationen der Version 7+ importiert werden. Formulare mit der alten //Status- und Aktionsverarbeitung// können in {{formcycle/}}-Installationen ab Version 6.2.0 importiert werden.
--* Die Werte für //AGB//, //Datenschutz//, //Impressum// für die Anzeige auf dem Anmeldebildschirm sind standardmäßig unbelegt. Wenn noch die Standardwerte verwendet werden, werden diese beim Update auf V7 geleert.
--* Aktualisierung von in {{formcycle/}} verwendeten Abhängigkeiten.
--* Diverse Fehlerbehebungen.
--
--
--=== Neue Platzhalter ===
--
--; [%$COUNTER_CLIENT.<name>%]
--: Gibt den aktuellen Wert eines Zählers zurück.
--; [%$RECORD_ATTR.<customAttrKey>%]
--: Auslesen von benutzerdefinierten Vorgangswerten.
--; [%$STATUS_TYPE%]
--: Gibt den Statustyp eines Vorgangs zurück.
--; [%$RECORD_READ%]
--: Ist der aktuelle Vorgang gelesen?
--; [%$RECORD_UNREAD%]
--: Ist der aktuelle Vorgang ungelesen?
--; [%$<AKTIONSNAME>.ERROR_CODE%]
--: Fehlercode zur Identifizierung von potentiellen Aktionsfehlern im neuen Workflow.
--; [%$<AKTIONSNAME>.ERROR_MESSAGE%]
--: Fehlernachricht bei potentiellen Aktionsfehlern im neuen Workflow.
--; [%$TRIGGER%] & [%$TRIGGER.<JSON_PATH>%]
--: Systemplatzhalter zum Auslesen von Daten, die ein Ereignis bereitstellt. Beispielsweise stellt das Double-Opt-In-Ereignis Informationen über die Aktion bereit, die den Double-Opt-In initialisiert hat.
--; [%$LAST_ERROR_CODE%]
--: Bei Fehlern im neuen Workflow gibt dieser Code den Typ des Fehlers an.
--; [%$LAST_ERROR_MESSAGE%]
--: Detaliertere Nachricht für Fehler im neuen Workflow.
--; [%$LAST_ERROR_NODE_NAME%]
--: Name des Knoten im neuen Workflow, der einen Fehler ausgelöst hat.
--; [%$LAST_ERROR_NODE_TYPE%]
--: Typ des Knoten im neuen Workflow, der einen Fehler ausgelöst hat.
--; [%$LAST_ERROR%] & [%$LAST_ERROR.<JSON_PATH>%]
--: Der Platzhalter [%$LAST_ERROR%] liefert ein JSON-Objekt mit Informationen zum letzten Fehler zurück, auf welche per JSON-Path zugrgriffen werden kann.
--; [%lang%]
--: Platzhalter zum Auslesen der Sprache, mit der ein Formular aufgerufen oder abgesendet wurde.
--; [%xf-qualifier%]
--: Platzhalter zum Auslesen des Namens der Button-Leiste, in der sich der Absendebutton befindet, mit dem das Formular abgesendet wurde.
--
--=== Plugins ===
--
--* Neue Pluginschnittstellen für Aktionen und Ereignisse im neuen Workflow. ([[IPluginProcessing>>doc:Formcycle.PluginDevelopment.Types.IPluginProcessing.WebHome]] gilt nur für die alte [[Status- und Aktionsverarbeitung>>doc:Formcycle.UserInterface.MyForms.WorkflowProcessing.WebHome]]).
--* Die [[Pluginschnittstellen>>doc:Formcycle.PluginDevelopment.Types.IPluginProcessing.WebHome]] der alten [[Status- und Aktionsverarbeitung>>doc:Formcycle.UserInterface.MyForms.WorkflowProcessing.WebHome]] wird nicht aktiv weiterentwickelt. Bestehende Plugin-Aktionen sollten für den neuen Workflow angepasst werden. //IPluginFormPreRespondParams#getWorkflowResponse// ist deprecated, es sollte //#getTaskExecutionResult// für den neuen Workflow verwendet werden.
--* Neue Plugin-Schnittstellen für die Unterscheidung von Plugin-Scopes: //IPluginScopeClient// & //IPluginScoopeSystem//
--* Es wurden einige Abhängigkeit aktualisiert. Plugins, die Abhängigkeiten als //provided// einbinden, müssen prüfen, welche Version von FORMCYCLE ausgeliefert wird und ob diese mit dem Plugin-Code kompatibel ist.
--* Es wurde auf [[CDI 2.0>>https://jakarta.ee/specifications/cdi/2.0/]] und [[JSF 2.3>>https://jakarta.ee/specifications/faces/2.3/]] aktualisert. Plugins mit eigener Oberfläche (XHTML / Beans) müssen entsprechend geprüft werden und sollten CDI (Contexts and Dependency Injection) verwenden.
--
--=== Hinweise ===
--
--* Das initiale Einrichten der Datenbank kann unter MySQL (vor allem Version 5) etwas länger dauern (~1 1/2 Stunden), wenn das //information_schema// verwendet wird. Es kann der Parameter "useInformationSchema=false" an die JDBC-URL angefügt werden, um diese Zeit zu reduzieren (auf etwa ~10-20 Minuten).
--* Es gibt neue Cookie-Richtlinien in aktuellen Browsern. Standardmäßig wird nun //SameSite=Lax// angenommen. Damit funktioniert etwa die AJAX-Einbindung von Formularen nicht mehr, da der Session-Cookie abgewiesen wird. Es muss nun //SameSite=None// gesetzt werden. Unter //System -> Allgemein// kann festgelegt werden, welche Einstellungen für den Session-Cookie gelten sollen, siehe auch die Hinweise dort. Zudem erfordert //SameSite=None// das Secure-Flag, die AJAX-Einbindung funktioniert daher in neuen Browsern nur per HTTPS!  Das Standardverhalten ist, dass //SameSite=None// und das Secure-Flag gesetzt wird, wenn FORMCYCLE über HTTPS aufgerufen wird (bei Proxy-Servern ist es nicht immer möglich, zu erkennen, wie das Request durchgeführt wurde). Wenn sicher ist, dass immer HTTPS verwendet wird, kann es in den Einstellungen so eingestellt werden, dass //SameSite=None// und das Secure-Flag immer gesetzt wird.
--* Bitte überprüfen Sie Ihre RSS-Feeds, wenn sie diese abonniert haben. Möglicherweise haben sich die URLs für der Feeds geändert.
--
  {{/localize}}
  {{localize language="en"}}
  All information about this and all future versions can be found in the new help for version 7: [[https://help7.formcycle.eu/xwiki/bin/view/Blog/>>https://help7.formcycle.eu/xwiki/bin/view/Blog/]]
--
--{{info}}{{formcycle/}} 7 requires at least **Java 11+**. Please note that Java 15/16/17 are not supported currently.{{/info}}
--
--{{info}}Before you install the update, please check whether all plugins you need are available for {{formcycle/}} 7. You can find all available plugins in the download section as usual: [[customer.formcycle.eu>>https://customer.formcycle.eu]].{{/info}}
--
--{{info}}A new updated license is required for {{formcycle/}}. Please contact support if you do not have one already.{{/info}}
--
--{{info}}Until now, web sockets were optional. Starting with {{formcycle/}} 7, web sockets are required and must be supported by the application server and network. This may require opening certain ports.{{/info}}
--
--{{info}}In case you are using a custom protocol stack configuration file for the cluster mode, you will need to update it (see the configuration file //cluster.properties//, entry //cluster.protocol.file//). //JGroups// was updated to version 5 which has dropped support for some old protocols and changed a few settings. See also the [[JGroups upgrade guide>>http://www.jgroups.org/manual5/index.html]]{{/info}}
--
--=== New visual workflow designer  ===
--
--(% style="text-align:center" %)
--[[image:feature_workflow_designer_de.png||height="400"]]
--
--The new //visual workflow designer// lets you customize how form data is processed in a new and intuitive way via drag & drop. Until now, the old workflow engine was based on states and state changes. With the new workflow engine comes a new paradigm ~-~- event-based processing. You can drag & drop events to the flowchart area and add actions that you wish to run when the event occurs. {{formcycle/}} ships with many standard events such as: an event when the form was submitted via submit button, when the user has confirmed the double opt-in, time-based events that occur at a specified point in time, and many more. More events can be added via plugins. Conditions are now representend graphically as a fork in the flowchart, and you can also add multiple conditions connected via AND and OR.
--
--The new workflow engine and the new workflow designer represents the future of form data processing with {{formcycle/}}. Later versions of will add more events and actions. The [[old workflow engine>>doc:Formcycle.UserInterface.MyForms.WorkflowProcessing.WebHome]] and the old workflow tree still exists and can be used, but is deprecated and will be removed in an upcoming release. Whenever possible, prefer the new workflow designer, and update existing forms.
--
--=== Additional features ===
--
--; W3C compliant mode
--: The new form setting //W3C compliant mode//, when enabled, ensures that the HTML created for the form is well-formed and complies with the [[W3C specifications>>https://www.w3.org/]] . This settings is enabled by default for all newly created forms, and disabled for existing forms. When enabled, certain HTML attributes such as //cn=...// and //xn=...// are omitted, as these are not W3C compliant. When you enable this mode for existing forms, you may have to update JavaScript and CSS selectors. Use //[data-cn=...]//, //[data-name=...]//, //[data-xn=...]// etc. instead. These //data// attributes are always added, even when the W3C mode is disabled, so you can upgrade your JavaScript and CSS one step at a time.
--
--; Submit button validation
--: The new form setting //Validate submit button// prevents malicious users from manipulating the workflow. In the old workflow, it was common to check whether a certain button was used to submit the form and perform certain action if so. This presents a problem, however: Even when a submit button was not available in a certain state, users could still set the submit button name to that button's name. When the //Validate submit button// setting is enabled, this is no longer possible, the system now checks whether the button is truly available. This setting is enabled by default for newly created forms. We recommend you leave this setting enabled. In some cases you may have to disable it, such as when you wish to use custom submit buttons created via JavaScript.
--
--; Form element name refactoring
--: When you change the name of a form element, certain references may not work anymore, such as when the form element is selected via JavaScript or CSS, or via form placeholders. The new //refactoring dialog// lets you search for and replace these references.
--
--; Counter
--: The new //counter feature// lets you define an arbitrary number of global counters for keeping track of incremental numbers. You can change, increment and decrement counters via the new //counter workflow actions//. Finally, you can also access the current value of a counter via system variables.
--
--; New workflow action: //Set server attribute//
--: The new workflow action //Set server attribute// lets you store custom data on a form record. To read the custom attributes, you can use a special placeholder variable.
--
--; New workflow action //LDAP query//
--: Similar to the database query action, the new workflow action //LDAP query// lets you retrieve data from an LDAP server from within the workflow.
--
--; Headers for the //POST request// actions
--: You can now specifiy additional and custom HTTP header parameters in the workflow action //POST request//.
--
--; Access form record attachments in the new workflow
--: For workflow actions where you can select files, you can now also select attachments from the form record, such as for the  attachments of an //email action// or the files for the //Save to file system action//.
--
--; Login protection for each state
--: Previously, you could only select the allowed login methods globally for each form. This is now possible for each state separately. You can choose whether a login is required at all, and if so, how the user may log in.
--
--; //OAuth 2.0// support for external users
--: You can now add //OAuth 2.0// identity providers when users open a form.
--
--; Context-sensitive logging pattern parameters
--: [[Logging patterns>>doc:Formcycle.SystemSettings.UserInterface.Logging.WebHome]] now support several context-sensitive parameters such as the current form record ID. This may be useful when you need to analyse log files on a system with a high load.
--
--=== Changes ===
--
--* Locked form record can be unlocked in the inbox, such as when a form record is saved or a double opt-in is in progress. This requires a user to have a special role permission.
--* Form records waiting for a double opt-in confirmation can be checked and the double opt-in email can be sent again. This requires a user to have a special role permission.
--* Scheduled actions are shown in the history of a form record in the inbox. This includes //timed events//.
--* A new role permission was added for editing the form version of a form record in the inbox.
--* The action //Redirect// of the new workflow now lets you enter a URL directly.
--* The new form setting //Add name as CSS class//, when enabled, adds a CSS class with the name of the form element. This makes it easier to select form elements via JavaScript and CSS: //$(".tfEmail")// instead of //$("[data-name='tfEmail']")// This settings is enabled by default for newly created forms.
--* Even when a plugin bundle is disabled, the plugins contained in the bundle are still shown.
--* The HTML template //system information// was deprecated and should not be used anymore.
--* Forms are always exported in the new format. Support for the compatibility format was dropped. Export files with the old format can still be imported. Importing forms with the new workflow requires at least {{formcycle/}} version 7.0.0. Importing forms with the old workflow requires at least  {{formcycle/}} version 6.2.0.
--* The values for the terms of services, the imprint, and the privacy policy are unset by default. When you update {{formcycle/}} and these properties are set to their previous default values, these values will be cleared.
--* Dependencies used by {{formcycle/}} were upgraded.
--* Various bugs and issues were fixed.
--
--
--=== Neue Platzhalter ===
--
--; [%$COUNTER_CLIENT.<name>%]
--: The current value of counter.
--; [%$RECORD_ATTR.<customAttrKey>%]
--: The current value of a custom form record attribute.
--; [%$STATUS_TYPE%]
--: The type of the current state of the form record. Either //CUSTOM// or //RECEIVED//.
--; [%$RECORD_READ%]
--: Whether the form record was marked as read.
--; [%$RECORD_UNREAD%]
--: Whether the form record was marked as unread.
--; [%$<AKTIONSNAME>.ERROR_CODE%]
--: Error code of a workflow action, when that action was not successful.
--; [%$<AKTIONSNAME>.ERROR_MESSAGE%]
--: Error message of a workflow action, when that action was not successful.
--; [%$<AKTIONSNAME>.ERROR.<JSON_PATH>%]
--: Error data of a workflow action, when that action was not successful.
--; [%$TRIGGER.<JSON_PATH>%]
--: Lets you access the data of the workflow trigger of the current processing chain. For example, the double opt-in event lets you access the workflow action that initiated the workflow.
--; [%$LAST_ERROR_CODE%]
--: The error code of the most recent error that occurred in the new workflow.
--; [%$LAST_ERROR_MESSAGE%]
--: The error message of the most recent error that occurred in the new workflow.
--; [%$LAST_ERROR_NODE_NAME%]
--: The name of the node (action) that most recently failed.
--; [%$LAST_ERROR_NODE_TYPE%]
--: The type of the node (action) that most recently failed.
--; [%$LAST_ERROR.<JSON_PATH>%]
--: The data provided by the most recent error that occurred. This is a JSON value, you can access individual entries via a JSON path.
--; [%lang%]
--: The language used when the form was opened or submitted.
--; [%xf-qualifier%]
--: The qualifying name of the submit action, similar to //[%xf-action%]//. This is usually the name of the button list which contains the submit button that was pressed.
--
--=== Plugins ===
--
--* New plugin interfaces for //nodes (actions)// and //triggers (events)// of the new workflow.
--The interface ([[IPluginProcessing>>doc:Formcycle.PluginDevelopment.Types.IPluginProcessing.WebHome]] applies only to actions of the [[old workflow engine>>doc:Formcycle.UserInterface.MyForms.WorkflowProcessing.WebHome]]).
--* The plugin interface [[for old workflow actions>>doc:Formcycle.PluginDevelopment.Types.IPluginProcessing.WebHome]] is deprecated and support will be dropped in an upcoming release. Existing workflow action plugins should be updated for the new workflow.
--* Plugins that make use the //de.xima.fc.entities.Status// entity should be reviewed. This is the state of the old workflow engine. Form records created with the new workflow engine will not have any //de.xima.fc.entities.Status//. The new workflow engine uses //de.xima.fc.entities.WorkflowState//.
--* //IPluginFormPreRespondParams#getWorkflowResponse// is deprecated, you should use //#getTaskExecutionResult// for the result of the new workflow.
--* New interface for differentiating between different plugin scopes: //IPluginScopeClient// & //IPluginScoopeSystem//
--* Some dependencies were updated. If you have plugins that include these dependencies as //provided//, you should update the version and check whether you code is still compatible with the new version provided by {{formcycle/}}.
--* Update to [[CDI 2.0>>https://jakarta.ee/specifications/cdi/2.0/]] and [[JSF 2.3>>https://jakarta.ee/specifications/faces/2.3/]]. Plugins with custom user interfaces (XHTML / Beans) should be reviewed. Beans should use CDI (Contexts and Dependency Injection).
--
--=== Notes ===
--
--* When you use MySQL, the initial setup may take a long time (up to 90 minutes, especially with MySQL 5) when the //information_schema// is used. You can add the parameter "useInformationSchema=false" to the JDBC-URL to reduce the required time to about 10 - 20 minutes.
--* Recent browser version have introduced a new cookie policy. By default, a cookie is now set with //SameSite=Lax//. This breaks forms included in your page via AJAX, as browsers will reject the session cookie. Servers must now set //SameSite=None//. Furthermore, //SameSite=None// the //Secure// flag to be set, which in turn requires HTTPS. This means that including forms via AJAX requires HTTPS for new browsers! You can change the value of the //SameSite// cookie option via //System -> General//, see also the notes in that menu.  The default value for this option should work in most cases. The default behavior is that //SameSite=None// and the //Secure// flag is set when a form is opened via HTTPS. However, when you use a proxy server, depending on its configuration, it may not be possible to detect whether HTTPS is used. If you are certain you always use HTTPS, you can change the default setting so that //SameSite=None// and the //Secure// flag is always set.
--* Please the your RSS feeds if you are subscribed, the URL may have changed.
--
  {{/localize}}