edoras one - Release Notes

Version 1.5.0.S75


Hello everyone

CLD 1.5.0.S75 of edoras one is now available:
https://confluence.edorasware.com/display/EDWDEV/CLD+1.5.0.S75

In the release 1.5.0.S75 we introduced the possibility to force the archivation of cases. This means that you are now able to force archive a case even if the case has active child tasks or child processes which are running. These child entities are then interrupted and the case can be archived. The archive action offers several levels on how to force the archive.

The image component model has now a new target attribute. This allows the modelers to define the target attribute of the navigation link of the image component.

In the CMMN part of edoras vis we introduced the applicability rule attribute for Task, Human task, Process task, Case task, Collapsed stage and Expanded stage components.

A big refactor has been made on the Spring configuration files to simplify the integration of edoras one. Please have a look at the migration notes before doing an upgrade to 1.5.0.S75, because a lot of things have been changed, moved, renamed etc. All the migration steps are well described but the time for the upgrade may differ from project to project. Please also have a look at the bootstrap project for a reference on how to integrate edoras one with the new changes.

We also prepared the codebase and refactored some parts for the upcoming upgrade of AngularJS to the latest 1.2 version.

Besides the things mentioned above, we have added various small improvements and many fixes.

Regards, edoras one team

High-level Goals

  • Ability to force the archive action on a case
  • Add target attribute to image component
  • CMMN: Model applicability rules of discretionary items
  • Refactor Spring configuration files for a simplified integration of edoras one

Migration Notes

  • The integration-context-${application.environment}.xml files have been moved to the edoras-one-hosted module. They have also been renamed to integration--config.xml. This means that each project which does not use the edoras-one-hosted module, needs to add a integration config with the appropriate mail sender.
  • We dropped the support for XML based forms in old apps. With this change the ${edorasVisFormXmlToJsonRestUrl} system property can be removed.
  • The following system properties have been removed as we are now able to use relative paths. You are able to remove the ${modelerHost}, ${modelerPort}, ${modelerContextPath} system properties.
  • The content provider has been moved to the edoras-one-hosted module and needs to be defined by your own if you just use the edoras-one-server-core dependency. Please have a look in the one-application-context.xml in the edoras-one-hosted module on how to define a proper content provider.
  • In the vis-handler-config.xml remove the bean declaration for the class com.signavio.warehouse.directory.handler.EdorasFormXmlToJsonHandler. The vis-handler-config has also been renamed to vis-rest-config.xml
  • We moved the transfer configuration into the edoras-one-server-core module which means that the custom projects doesn't need to add an own transfer configuration if you just need it for preinstalled apps. For this we added a new system property '' which sets the location of the preinstalled apps. If you need to override this, then define the transfer configuration by yourself.
  • The one-hosted-application-context.xml has been renamed to one-application-context.xml. The one-hosted-rest-context.xml has been renamed to one-dispatcher-servlet-context.xml.
  • The tenant.data.location system property default has been changed to classpath*:/com/edorasware/one/tenants/*.json and the apps.preinstalled.location (the location of the preinstalled apps) system property has the value classpath*:/com/edorasware/one/apps/*.zip.
  • The one-rest-context.xml has been moved from the /config to the /com/edorasware/one/config package and renamed to one-rest-config.xml
  • We now use the Spring profiles for the database configuration inside the edoras-one-hosted module. The default is 'H2' and it can be changed by setting the spring.profiles.active property with the needed profiles. Please have a look at the database-config.xml file inside the edoras-one-hosted module.
  • We now use the Spring profiles for the integration configuration inside the edoras-one-hosted module. The default is 'development' and it can be changed by setting the spring.profiles.active property with the needed profiles. Please have a look at the integration-config.xml file inside the edoras-one-hosted module.
  • The system properties for the mail sender have changed. Please have a look at the one.properties file and the integration-config.xml file inside the edoras-one-hosted module.
  • The vis-application-context.xml has been moved from the edoras-one-hosted module to the edoras-vis-server module into the /com/edorasware/vis/config package.
  • The supportedBrowserEditorRegExp system property has been added with Firefox[/\\s]|MSIE 9.0|Trident/[5-7]\\.0|AppleWebKit|Opera.9\\.\\d+ as value.
  • In the vis-application-context.xml remove the lazy-init='true' flag set on the bean declaration for the class com.edorasware.bpm.modeler.config.PaletteConfiguration.
  • In the vis-application-context.xml add a new bean declaration for the class com.edorasware.bpm.modeler.config.ModelerConfiguration. To this bean declaration add two constructor-arg elements, one constructor-arg element with name='editorConfiguration' and ref='editorConfiguration', and a second constructor-arg element with name='paletteConfiguration' and ref='paletteConfiguration'. To the same bean definition, add a property element with the name='supportedBrowserEditorRegExp' and value='${supportedBrowserEditorRegExp}'.
  • In the web.xml remove the context-param elements which have the param-name as contextInitializerClasses and supportedBrowserEditor

Limitations

  • None