Dear customer
Release 2.0.0 brings a lot of new features, improvements and several upgrades. Please check the relevant sections for more detailed descriptions.
Best regards,
the edorasware team
Migrating between edoras one versions
Under our updated release policy, two simple principles are used to determine if moving from one version to another is supported. Starting with release 1.6:
-
downgrades are not supported
-
we support moving from any minor/patch version of a major version to any minor/patch version of the next major version
Before release 1.6.0 all releases had a 1.5.0-Sxxx version number. The above rules do not apply to those versions and we have dropped automatic migration to 2.0 from all releases prior to 1.6.0. If you have an older (1.5.0-Sxxx) release and want to upgrade, you will have to do this in two steps:
-
migrate to any 1.6.x release (we recommend the latest version available at the time of the migration)
-
migrate to the target 2.x release
This enables us to keep a cleaner codebase and focus on features and improvements, rather than maintaining stale migration code.
If you try to migrate directly from an unsupported release, the server will not start and an error will be written to the server log.
Upgrades
Java 8
We have switched to Java 8. Java 7 development and runtime environments are no longer supported.
Spring 4.3.7
We have upgraded the Spring core framework to the latest 4.3.7
release, and the Spring-based libraries to their
latest compatible versions. We have also upgraded all related 3rd party libraries.
These upgrades fix a number of security issues and add more customization features, and we are able to further improve our codebase and use the new improvements in the platform.
Flowable 6.1.2
The process engine has been upgraded to Flowable 6.1.2. To familiarize yourself with Flowable 6 capabilities please refer to the Flowable documentation.
Since Flowable 6.0.0, debugging capabilities have been extended a lot. The debugger provided in Flowable 6 is incompatible with the debugger supported in previous edoras-one versions. The experimental edoras one debugger has therefore been removed. We plan to support process debugging again in a future product version.
Third-party libraries
We have upgraded many third-party library dependencies. Please check the upgrade notes for details.
Deprecations and removals
Document editing
Since the Java Applet used for document editing is unsupported in modern browsers we’ve removed the applet support.
GenericWorkObjectService
The new public work object API provides the same functionality as GenericWorkObjectService
and so the latter
has been removed.
Java API
We have introduced a public Java API in the package com.edorasware.api
for use by application code.
The public Java API is documented in the public API Javadoc.
API annotations
We have introduced new API annotations in the package com.edorasware.api.annotation
that give some guidance about the way that classes and interfaces in the API package are intended to be used:
@Experimental
-
Experimental APIs are provided to allow users to try out new functionality but may be changed at any time without an official migration path.
@ExtensionPoint
-
Extension points are APIs that are intended to be used by customers to customize the behaviour of edoras one. The javadoc for the annotated class should provide details of how the extension point should be used.
Work object API
This release contains a new public work object API providing the following benefits:
-
unified 'value' interface that no longer distinguishes between fields and variables
-
stable data storage with a reduced set of serialized data types
-
single interface for all work objects regardless of type
-
simplified creation of query predicates using new value accessors
-
timestamps are represented using the new Java time classes, making time handling much easier
-
all IDs, State and Type values used in the API are now plain strings and are no longer typed
The new interfaces are defined in the package com.edorasware.api.workobject
.
Legacy edoras gear interfaces
To implement the new public Java API significant changes have been made to the legacy edoras gear implementation. Where possible, application code should use the new public API but there may be places where this is not possible or practical. The major changes to the legacy gear interfaces are:
-
the work object type hierarchy has been simplified. All work objects are now of one type (
AnyWorkObject
) and there is only one service (AnyWorkObjectService
) and one set of corresponding support classes (providers, listeners etc.). -
all IDs, State and Type values are now plain strings and are no longer typed
-
timestamps are represented using the new Java time classes
Elasticsearch integration API
Some minor changes were made to the elasticsearch integration API to:
-
simplify the interface
-
support application code that generates index configurations
-
allow index configurations to require an explicit synchronization request (i.e. opt-out of the 'synchronize-all' processing)
Simplified tenant handling
The tenant handling has now been simplified, removing the 'shared' tenant support and separate modes for single- and multi-tenant operation. The system now always runs in multi-tenant mode (although it may just have one tenant configured).
Configuration API
In this release we moved from the Spring XML configuration to its Java counterpart. In addition we introduced our own configuration API which is our public API for configuring edoras one. This API eases the configuration and ensures API stability. See the upgrade notes for further information.
Configuration properties
As part of the move to Spring Java configuration, the application configuration properties have been revised and made consistent. Please refer to the upgrade notes for information on the changed property names.
CORS configuration
The CORS configuration can now be controlled using properties. By default all domains, origins and headers are allowed on all paths. If you want to change these settings please refer to the CORS configuration section of the documentation.
REST API
In this release we introduced our new public REST API. Please check the upgrade notes on how to access the API documentation.
Front end API
New app.loaded event
There is now an event triggered on API initialization called app.loaded
. You can subscribe to that event from custom.js
like this:
angular.module('one.custom').config(() => {
/* event.type === "app.loaded" */
const onAppLoaded = event => window.postMessage(event.type, 'Event destination window');
edoras.eventLog.subscribe(onAppLoaded);
})
This will trigger the onAppLoaded
function when the application is loaded.
chain() performance
The edoras.chain()
method ensures that subsequent commands are run against a stable UI.
Stability is defined as no updates for a certain period of time.
The wait time period can now be configured using a one.properties
setting:
ui.debounce-time-viewengine-api-chain = 500
You can decrease the debounce time to make chains faster.
If scripts that use the edoras.chain()
method (e.g. in script buttons) behave erratically then you may
need to increase the debounce time.
CSS styling
Model state classes
We add classes to column elements depending on model state:
-
eo-column-validation-required
when the column field is required (including runtime expressions). -
eo-column-invalid
oreo-column-valid
when the column field model is invalid/valid (with any validation: required, maxlength, etc.) -
eo-column-dirty
oreo-column-pristine
when the column field model is dirty/pristine.
This eases the styles customization depending on form data state. No new CSS rules have been added to default CSS files, so this does not change the UI by default.
Frontend Templating
New parameters available to Optionally remove scripts from embedded.html
When using the embedded.html template, you can use new url parameters to avoid loading unnecessary resources. To avoid loading a set of resources, set the corresponding GET url parameter to "true". The available parameters are:
-
nv
: Won’t load vis related resources. -
nc
: Won’t load custom related resources. -
nw
: Won’t load widgets related resources.
Example of url to avoid the load of vis:
/embedded.html?nv=true
Modelling changes
App compatibility
Due to changes in the App format, Apps exported in this release can no longer be read by earlier edoras one versions.
Disallowing all actions in a case, task or document model
Previously, disallowing all actions on a case, task or document required a workaround,
specifically to add only the Create Variables
default action. This action is only available to
users in the Modelers group, so end users would not have default actions to their disposal.
We’ve now removed the need for the workaround. To disallow all default actions you can simply use an empty Allowed Actions
list.
Existing models do not need to be changed, but you are now free to remove the Create Variables
workaround if you so wish.
Form models
New select and autocomplete components
The Select and Autocomplete Select components have been replaced with the new Single and Multi Select components. Their data source and behaviours are now fully configurable and the user experience is consistent.
CMMN case models
Send Email Service Task
Sending an e-mail from CMMN is now supported directly through a 'Send Email' service task.
Mail models
Mail model allows back-end expressions
Currently there are two ways of sending emails:
-
on the creation of a user task in a process
-
by using the
Send Mail
service task
Both are configured in the same way, meaning that in the past you needed to select the mail model with a select box based on the mail models in the app.
It is now possible to add a runtime expression using the new Mail Model RT
attribute. This should define a back-end expression
that resolves to either a mail model ID or mail definition key (i.e. a specific deployed mail definition). In the first case,
the latest deployed definition of the model is used as the mail template. In the latter case, the specified definition will be used.
You will find more information in the 'Send Mail' service task section of the documentation.
Configurable mail model defaults
There are three default mail models which are used for the following email notifications:
-
When a work item is assigned to you.
-
When a work item is created and you are a candidate user.
-
When a work item is edited only if you are an assignee or the owner.
These mail models were linked to the respective mail model in the system app. Now this has changed and you are now able to override these mail models easily. To do that you need to set the following system properties for the respective mail model:
# The default mail models (in the system app) based on a mail model model ID. Be aware that always the latest deployed mail model definition, based on the specified model ID, will be used.
mail.model.assignee.model.id = MAIL_MODEL-ec56a716-36c7-4850-8081-5daa9912872f
mail.model.candidate.groups.model.id = MAIL_MODEL-499f4935-0987-46ba-ac1e-ba6632927f16
mail.model.edited.model.id = MAIL_MODEL-0252639c-df22-4d4e-9262-0890587c192f
Each value of such a property is the model ID of the mail model (technically the global ID of the model work object). The defaults that are set now are the model IDs of the mail models in the system app such that the default behavior stays and you could now override the default easily.
Decision models
In this release we added experimental decision table (DMN) support. You are able to create decision models in the modeler dashboard and execute the rules in your process with a 'Decision Task' service task.
Support for the decision table work object type DET
when searching is temporary and should not be
used in hardcoded queries, as it may be removed in a future release.
App export uses App name
When exporting an App, the default filename is now configurable.
Graphical modeler improvements
-
Case name is now mandatory for 'Create Case (from Subform)' service tasks
-
The Link component text now supports translations (i18n)
-
A warning is shown when a mandatory field is invisible
URL encoding in models
We’ve dropped support for the backwardcompatibility.urlencoding
flag, which allowed the use of manually encoded URLs in models.
Elasticsearch Upgrade
We upgraded the Elasticsearch integration to support version 5.
Upgrade notes
Please have a detailed look at the upgrade notes for this version so that you are able to upgrade to the newer version in a controlled manner.
If you have issues viewing the email then click here to view the online version. If you want to unsubscribe from the release notes please send an email to unsubscribe@edorasware.com.