edoras one Documentation

1. edoras one Overview

1.1. What is edoras one?

edoras one comprises a new generation of integrated platform that combines business process management, case management and content management simply and effectively. It makes work processes much more economical. Running in the background, the platform guarantees quick access to whatever content is relevant for your company’s tasks. To achieve this, edoras one doesn’t rely on a rigid process structure. Instead, it’s based on "design by doing"; each individual user decides how much structure he actually needs and determines for himself which work fragment will help him achieve his task. All process steps have grown organically and, as such, are part of natural productivity. That means your company stays well organized in an unstructured world and sustains the dynamics necessary for success.

1.2. What is the main concept behind edoras one?

edoras one organizes everything you do around the concept of work items. No matter whether you create a single task, start a new case or process, or upload a document, everything is a work item and supports a common set of functionality like ownership and assignment, due date and priority. Forms are used to manage the data associated with work items. Work items can have relations to each other and support hierarchies. The behavior of a work item is driven by its model, which is called a definition. For instance a process is driven by its process definition which is modeled using the modeling standard BPMN 2. These models can be designed and configured within the modeler dashboard of edoras one. An edoras one App contains all types of models and configurations to support a specific aspect or area of your organization. An App can be deployed and all of its models become available to drive the behavior of your work items.

1.3. What is the concept behind "cases"?

The work item type called "case" is key in edoras one as it acts as the main context around a collection of work items and information. A case can represent many things depending on how you define it. Think of a case like a box with a label where you can find everything that you need to work on a particular task. There are small and large boxes, square and round ones, boxes with one compartment only or boxes with a lot of compartments to organize the contents. For example if you handle customer complaints with edoras one, a single "complaint" could become a "case" and everything that happens while solving that complaint can be stored in and made available in that case. Or if you use edoras one for your recruiting, each job applicant is represented by a "case" where all structured data like name, birthday etc. for the applicant is part of the case form and documents like CV and references are simply stored within the case as attachments. Another great fit for edoras one is request and approval handling where a vacation request, a travel request or even a request for a quote from a customer becomes a case, supporting the handling and approval process through edoras one.

1.4. What can I use edoras one for?

The best matches for edoras one are all types of processes where people are involved working and collaborating together, on-site or distributed, with internal colleagues and even external participants like customers or service providers - wherever data has to be collected, approved, discussed and solutions have to be found using a process style that is a combination of structured and unstructured, ad-hoc work. Let’s have a look at some examples.

1.4.1. Approval Processes

Think about a request in your organization which contains data that has to be approved, decided on and processed. Examples includes a vacation or travel request, an order form to be approved and processed, or access rights and permissions for applications that need to be approved by several people in your organization. An approval process could even be a typical e-government process, where a citizen submits an application for processing by the government. edoras one allows every participant to be part of the whole process as needed.

1.4.2. Help Desk

There is a lot of unstructured work in a typical help desk environment. It needs to be fast, nothing must be lost and the customer needs answers. From submitting a help desk request either via email or over the phone, it all starts with a need from the customer. Some requests such as ordering a new license or upgrading to a new version of your product. might be standard and can be fully structured or even automated. But complaint management or support issues are typically less structured and more driven by knowledge, not routine. That’s exactly where edoras one fits best: the combination of structured and knowledge driven work. If your help desk sees repeating patterns, start structuring them and you will gain added value every day, but even without any structure at all you will never loose a case in your help desk, you always have full access to all data, information and past discussions and you don’t miss a due date, at least not because of the tooling.

1.4.3. HR

HR processes are a great fit for edoras one as there are many people involved. Think of using edoras one in your recruiting process, let applicants apply for a job through an initital job application case form and upload their documents (CV, references etc.) . Then work on the application internally - everyone from HR people to superiors and managers that are part of the recruiting process can participate in the case and make it an effective place to collect information, have discussions and make decisions. Onboarding a new employee is another great example where a lot of people are typically involved - did you think about and remember everything that needs to be done? edoras one will help you with that organization. Once the employee has started work, vacation requests, expenses or travel requests are typical processes where edoras one is a great fit. How do I start using edoras one in my organization? Using edoras one is very simple and even without your own collection of processes, templates and forms, you can benefit from edoras one from the first day by using default templates like a simple case, ad-hoc tasks and review process. Start collecting feedback from the people working with those default templates and then start modeling your own processes, forms and templates accordingly in small steps. Adjust them, deploy them, use them and collect feedback again to constantly improve. That’s what we call "desgin by doing" where your App emerges from your organizational needs in small, but continuous steps.

1.5. What license do I need to work with edoras one?

There are two options to use edoras one, either on-premise or as a service in the cloud. Both options are based on the same license model which is built around three user types:

Agents
Participants
Modelers

Agents and modelers are licensed as named users and participants are all free of charge. An agent has full access to the edoras one features, except the modeling features. You have to be a modeler in order to access the modeling capabilities of edoras one. A participant is able to start new cases and is able to participate with full feature capability in all the cases he started. In foreign cases, a participant can be included for single tasks (like approval) with limited access to the case, for everything else, you need to be an agent to have full access to all features.

1.6. What are the supported runtimes for edoras one?

edoras one is available as a service in the cloud from edorasware directly, as a domain specific service in the private cloud from one of our partners or on-premise in your own infrastructure. On-premise, you can simply use edoras one as a platform and integrate it into your infrastructure and applications or you can even use edoras one as a development platform in order to build your own solution on top of it.

1.7. Architecture Overview

The following diagram shows the main components of edoras one.

Figure 1. Architecture overview

Web Container (e.g. Tomcat)
edoras one runs in a Java web-compliant container like Tomcat for instance. You can also deploy edoras one into a JEE compliant server like JBoss, although the JEE parts of the container are not necessarily needed but are integrated with, if available.
Client / Web Browser
edoras one is fully web-based and only needs a web browser to work with. Even the graphical modeling environment is fully running within the browser without the need of an extra plugin. The client part is based on HTML5 / CSS3 and uses a client side model-view-controller framework (AngularJS) to abstract the data from the view and the controllers.
RDBMS
All information within edoras one is stored transactionally within an RDBMS. The following database systems are supported by edoras one; Oracle, MS SQL Server, DB2, MySQL, PostgreSQL, H2 and Derby.
Content Repository
File-based content or large unstructured content is stored within the content repository of edoras one. There is a simple, built-in repository supporting a light-weight content storage system with built-in versioning capabilities. The content can also be stored in an external system like Alfresco, Sharepoint or the like using the CMIS protocol.
Search Infrastructure
edoras one supports a full text search integration, each work item is searchable as well as its content. The search can be integrated with the featured Java based query API or through the search REST endpoint, supporting full text search as well as structured search.
Work Item Infrastructure (edoras gear)
The core of edoras one is it’s work item infrastructure supported by edoras gear, the work management framework. You can read more about edoras gear later in this document.
Modelling Infrastructure (edoras vis)
Part of edoras one is the modelling infrastructure named edoras vis. It is embedded into edoras one for a smooth modeling experience, deploying directly into edoras gear and runtime experience using edoras one. For each supported type of models there is an appropriate provider interpreting that model. Process models for instance are modeled with the BPMN 2 standard and being executed by the process provider, based on the Activitit process engine. The form models are stored in JSON and rendered through the form engine in the client.
REST API
edoras one supports a REST API based on the JSON data protocol. The edoras one client actually uses the same API as well for all of its features. Additionally, the REST API can be used for any kind of integration with edoras one.
Extensions / Listeners / Providers
There are a lot of well designed extension points in edoras gear that can be used to extend the work item platform in many ways. Read more details about the extension points later in this document.
Client / Server Communication
The client / server communication is based on the REST API supported by the edoras one backend services. JSON is used for the data in the requests and HTTP / HTTPS as the transfer protocol. edoras one can be integrated with SSO infrastructures as well.

2. edoras one User Guide

2.1.1. Dashboards

When you log into edoras one, you will normally see the edoras one user dashboard:

The edoras one dashboards each provide a summary of information that is relevant to a particular user role, in this case the user’s active work items. Only work items that are visible to the current user are displayed. You can change between dashboards using the dashboard selector in the application toolbar:

that depending on the user’s permissions, some dashboards may be available.

2.1.2. List view

The dashboard widgets typically show a summary of a particular type of work item:

Clicking on the widget header will open the corresponding list view to show the full list of work items (the widget itself only shows the first few):

2.1.3. Work item page

Clicking on a particular item in the dashboard list will take you directly to the work item page where the work item details can be viewed and/or edited:

The work item page will typically provide a number of different work item views, which can be selected using the icons in the top right-hand corner:

and a number of work item actions in the action toolbar on the right hand side which can be used to perform operations on the work item:

2.1.4. Work item views

Browse view

The browse view shows the work item details and is available for all work items. Select the Browse icon to open the work item view:

This will show the work item work form and if the item is active then the details may also be modifiable:

Search view

The search view shows the current child work items and is available for container work items such as Apps and Cases. Select the Search icon to open the child work item view:

This will show the list of child work items:

$searchView$

Comments view

The comments view shows the work item comments and is available for all work items.

Select the Comments icon to open the comments view:

This will show the work item comments, including both automatically generated change notifications and user comments:

Preview view

The preview view shows a preview of the work item contents and is available for all work items with suitable content.

Select the Preview icon to open the comments view:

This will show the content preview, which depends on the work item content type. As an example, a form model preview will show a preview image of the form layout:

Edit entity view

The edit entity view allows all work items to be viewed and/or modified (not just those that are accessible through the normal work item forms). This is a technical view of the work item that is available for all work items but only for users with suitable access permissions.

Select the Edit Entity icon to open the entity editor view:

This will show the work item values as a form:

Edit entity JSON view

The edit entity JSON view allows all the raw work item definition to be viewed and/or modified. This is a technical view of the work item that is available for all work items but only for users with suitable access permissions.

Select the Edit Entity JSON icon to open the entity JSON editor view:

This will show the work item as a raw text field:

2.1.5. Bookmarking pages

Every page in edoras one has a unique persistent URL that can be bookmarked in the browser or referenced from a link. Simply add a bookmark or copy the page URL from the browser address toolbar.

When following a link to edoras one you may have to log in if the browser does not have active edoras one credentials. When the link points to a work item view, the view will only be shown if the user that is logged in has suitable access permissions for the work item in question.

2.1.6. Keyboard shortcuts

edoras one provides a number of keyboard navigation shortcuts:

Table 1. Keyboard shortcuts
Key	Description
`c`	create a new work item. The work item types that can be created are defined by the current dashboard. Select the work item type using the arrow keys and press `Enter` to create it.
`d`	change dashboard. Select the dashboard using the arrow keys and press `Enter` to open it.
`ctrl` + `s`	save form. Save the pending changes of a browse view or a create action.

2.2. Dashboards

2.2.1. User dashboard

The user dashboard provides a summary of the work items that are related to the workflows currently in progress in edoras one:

The work items shown in the user dashboard are:

Case: a container for related work items and processes.
Task: describes a task to be performed by a user.
Document: a document or other file.
Query: a stored search configuration.

2.2.2. Modeler dashboard

The modeler dashboard provides a summary of the workflow apps and models:

The work items shown in the modeler dashboard are:

App Model: a container for related models that combine to define a workflow. The workflow defined by the models can only be used when the app is deployed.
Case Model: defines a particular type of case.
Process Model: defines an executable workflow that combines several tasks, either manual or automated.
Task Model: defines a particular type of task.
Document Model: defines a particular type of document.
Form Model: defines a form used by other models to interact with a specific work item.

Please refer to the edoras one Modeler Guide for more details of the modeler dashboard and the modeler work items.

2.2.3. Admin dashboard

The admin dashboard provides a summary of the system administration work items:

The work items shown in the admin dashboard are:

Account: a container for related users and groups.
Group: defines related sets of users, and can also be used to grant permissions.
User: a particular user within the system.
App: the instance of an app model where the the dynamic properties can be updated.

Please refer to the edoras one Admin Guide for more details of the admin dashboard and the admin work items.

2.2.4. Management dashboard

The management dashboard provides a statistical work item overview:

2.3. User Profile

You can manage your profile by accessing the user profile. Click on your user name in the top right corner of the screen and select User Profile.

2.3.1. Change your email address

edoras one sends email notifications depending on your settings. to change your email address simply type the new address in the field Email address and save your changes by clicking save at the bottom of the profile

2.3.2. Change your language

edoras one currently supports english, spanish, german, french and italian as plattform languages. To change the language just select the desired language from the language dropdown and save your changes by clicking save at the bottom of the page.

Changing the language needs a page refresh after the save to become effective. Not every App has to be maintained in all languages. If your language is not maintained in a particular App, it defaults to the primary language defined by the issuer of the App.

2.3.3. Change your password

To change your password simply enter the new password in the password field (There are currently no restrictions about password strength). Then re-enter the password in the repeat password field and save your changes by clicking save at the bottom of the page.

2.3.4. Deputies

You are allowed to select users which can act as your deputies. Activated deputies can act on behalf of you. You can decide whether deputies are notified on the notification events. In the case when somebody else has chosen you as a his/her deputy you can impersonate the user by clicking on the user menu user name and Users to impersonate.

2.4. Avatar

edoras one uses the Gravatar online Avatar Service to load your avatar from the internet. If you don’t use gravatar yet and want to have a custom avatar in edoras one, sign up to Gravatar with the email address specified in your user profile by clicking on Create your own Gravatar on their website.

2.5. Search

2.5.1. Basic searching

To search for work items in edoras one, use the search functionality provided by the edoras one toolbar.

Clicking on the triangle to the right of the search field opens a pull-down dialog where a number of common search settings can be selected. As these options are changed, the results of the search are shown in the list view:

Typing a plain text value into the search text field will also restrict the search results to work items that contain the given text, either in the name, in the description, or in a string attribute value.

2.5.2. More complex searching

In addition to plain text search, the search text field supports a query language that allows more complex queries to be created.

Search terms

A query consists of a list of search terms separated by whitespace:

<term1> <term2> <term3> …

In the simplest case, a term can be a single word which performs a text search for work items that contain the given word. This is the basis for the search mechanism described in <basic-search>.

When searching, the search results from each term are combined with 'and', so each additional term restricts the search results more tightly.

To include whitespace in a search term, surround the search text with quotes (i.e. +'multiple word search').

More complex terms follow the pattern:

<termKey>:<expression>,<expression>,…

where the term key defines the type of search to be performed, and the list of expressions defines the values to be matched.

The values matched by the expressions are combined with 'or', so each additional expression extends the list of search results.

Expressions may also consist either of a single value (e.g. 123) or be an operator / operand pair, also separated by a : (e.g. gt:123).

As an example, the search term priority:1,3,gt:5 will return all work items that have a priority of 1, 3 or any value greater than 5.

The following search term keys are currently supported by edoras one:

Table 2. Supported term keys
Term key	Expression type	Searches by
app	Model expression	user work items based on models from matching apps
assignee	User expression	assigned user
created	Date expression	creation date
dashboard	Dashboard expression	work item type (using dashboard shortcuts)
descendantsOf	ID	hierarchy
description	String expression	work item description
desc	String expression	work item description (alias for description)
due	Date expression	due date
for	User expression	assigned user (alias for assignee)
model	Model expression	user work items based on matching models
name	String expression	work item name
owner	User expression	owner
parent	ID	hierarchy (alias for descendantsOf)
priority	Number expression	priority
state	State expression	state
text	String expression	textual content (the default search term key)
type	Type expression	work item type
updated	Date expression	last modified date
<variable name>	all	variable value

2.5.3. Sort terms

In addition to the search terms described above, a sort term may also be specified which allows the order of the search results to be specified. A sort term begins with sort:, is followed by an optional asc: (ascending, the default) or desc: (descending), and then the attribute to sort by. The following sort attributes are supported:

Table 3. Sort term values
Sort attribute	Description
assignee	assignee (grouping only, no alphabetical sort)
creation	creation date
due	due date
modification	last modified date
name	work item name
owner	owner (grouping only, no alphabetical sort)
priority	priority
type	work item type

Examples

sort:desc:name
sort:creation

2.5.4. User expression

A user expression accepts the following operand values:

Table 4. User operand values
Operand value	Matches
<ID>	the specific user ID (work object ID)
all	any assigned user
me	the current user
unassigned	unassigned work items (a value alias for the empty operator)
<text>	any user with the given text as part of the display name

The following operators are also supported:

Table 5. User operators
Value	Matches
empty:	unassigned work items

Examples

owner:empty:
owner:all
owner:me
owner:joe

2.5.5. Date expression

The following date operators are supported:

Table 6. Date operators
Operator	Operand value	Matches
eq:	date	values equal to the given value (default)
gt:	date	values greater than the given value
gte:	date	values greater than or equal to the given value
lt:	date	values less than the given value
lte:	date	values less than or equal to the given value
range:	date..date	values in the given range (inclusive)

The following date specification formats are supported:

Table 7. Date specification formats
Format	Description
yyyy-MM-dd	a specific date
[yY][mM][wW][dD]	a date relative to today in years, months weeks, or days
today	today’s date

Examples

created:today
created:lt:2014-02-14
updated:range:-2W..2W

Date values are currently interpreted in the UTC timezone, so a date-based search may occasionally contain unexpected results when viewed from a particular user’s local timezone.

2.5.6. Number expression

The following number operators are supported:

Table 8. Number operators
Operator	Operand value	Matches
eq:	<number>	values equal to the given value (default)
gt:	<number>	values greater than the given value
gte:	<number>	values greater than or equal to the given value
lt:	<number>	values less than the given value
lte:	<number>	values less than or equal to the given value
range:	<number>..<number>	values in the given range (inclusive)

Examples

priority:1,2
priority:gt:5

2.5.7. State expression

No special state operators are supported, only the following state operand values:

Table 9. State operand values
Operand value	Matches
all	all states (no restriction)
open	open work items (active, pending, pending inactive)
active	active work items
inactive	inactive work items
pending	pending work items
'pending inactive'	pending inactive work items (quotes are required)
completed	completed work items
archived	archived work items
interrupted	interrupted work items

Examples

state:open
state:archived,completed

2.5.8. Type expression

No special type operators are supported, only the following operand values:

Table 10. Type operand values
Operand value	Matches
CAS	cases
DOC	documents
TSK	tasks
QUERY	queries
APP	apps
CASE_MODEL	case models
DOCUMENT_MODEL	document models
FORM_MODEL	form models
MAIL_MODEL	mail models
PROCESS_MODEL	process models
TASK_MODEL	task models
APP_MODEL	app models
ACC	accounts
GRP	groups
USR	users

Examples

type:TSK,DOC

2.5.9. Dashboard expression

No special dashboard operators are supported, only the following operand values:

Table 11. Dashboard operand values
Operand value	Matches
admin	accounts, groups, users & apps
modeler	models
user	cases, task, documents & queries

Dashboard terms are just a shortcut for a type term with the corresponding type list.

Examples

dashboard:user

2.5.10. String expression

The following string operators are supported:

Table 12. String operators
Operator	Operand value	Matches
contains:	<string>	values that contain the given substring (default)
empty:	<string>	values that are not set
eq:	<string>	values that exactly match the given string

Examples

name:example
description:empty:

2.5.11. Model expression

The following model operators are supported.

Table 13. Model operators
Operator	Operand value	Matches
contains:	<string>	values that contain the given substring (default)
eq:	<string>	values that exactly match the given string

The operand value is used to perform a name search on apps or models (depending on the term). For the app term, all models from the matching apps will be selected, for the model term only the matching models will be selected.

The search results will consist of all work items that were created from one of the selected models.

Examples

app:vacation
model:eq:'Vacation Request Case'

In order to retrieve the corresponding work items, permissions to access the corresponding models are needed.

2.6. Glossary

app model: an app model is a container for a collection of models that define a specific workflow.
dashboard: a page in the edoras one application where work objects can be found, displayed and manipulated. Each dashboard manages related work object types that play a given role within the system.
model: a description of a workflow component which can be deployed together with other models to create a executable workflow in edoras one
operand: the value part of a search term expression.
operator: the optional first part of a search term expression which says how the operand value should be interpreted.
process: a process is a workflow definition, described using a BPMN 2.0 model and executed within edoras one. It typically defines the automated and manual tasks that must be performed to complete the workflow.
search term expression: part of a search term. A search term can contain multiple expressions, separated by commas. The result set for the term contains work items that match any of the operators. A search term expression contains an optional operator, and an operand value.
search term: part of a search query. The result set for the query contains work items that match all of the separate terms.
task: a task is a single action within a workflow, and may be either automated (a service task) or manual (a user task).
work object / work item: an item that can be created or manipulated in edoras one. Different types of work item are supported. The work object types are typically grouped according to their role within the system and accessed through dashboards.

3. edoras one Modeler Guide

3.1. Modeler Overview

The modeler dashboard can be accessed by authorized users through the dashboard menu and is used to create and deploy workflow models for use within edoras one.

Before we look at the details of the modeler dashboard it will help to understand how models are related to the user dashboard.

Models are created edited in the modeler dashboard, and as long as they are only edited they are not visible in the user dashboard. When models are deployed, corresponding definitions are created. These definitions can be used in the user dashboard to create work objects of the new type.

3.1.1. App Models

An edoras one App model contains a collection of different models that combine to define a specific workflow within edoras one.

An app model can be created and then different models can be added and linked together as required. When the workflow is ready, it can be deployed to create the corresponding definitions which are used to execute the workflow, and it can then be tested.

App models can be transferred between different edoras one installations using the Export and Import actions.

3.1.2. edoras vis

edoras vis is a modeler with focus on modeling BPMN 2.0-compliant processes, edoras one compliant forms and CMMN 1.0-compliant case models.

3.2. Model types

3.2.1. Form model

A form model defines a form that can be used by other workflow models to interact with the user. Each form contains a number of form fields arranged in a given layout. The fields in a form may contain predefined content, or may be bound to work object values at runtime, for example to allow the name and description of a document to be displayed and perhaps changed.

Typically two types of forms are used: init forms are used to initialize new work objects, and work forms are used to edit existing work objects.

Form models can be quickly checked by hovering over the form name, previewed within edoras one using the Preview view or edited in the edoras vis modeler using the Design action. It is also possible to download the XML form definition using the Download action.

3.2.2. Task model

A task model is used to define a new type of user task. The init and work forms for a task are used to create and edit the task contents, and are set using the Browse view. The default candidate groups used for sharing can also be set, and the actions that will be allowed on this type of task can also be selected.

3.2.3. Document model

A document model is used to define a new type of document. As in the task model, the Browse view allows the init and work forms to be selected, as well as setting the candidate groups and allowed actions. Moreover, the placeholders can also be defined in this view.

Skeleton documents

A skeleton document can be set using the Upload skeleton action. If a skeleton document is provided then whenever a new document of this type is created it will be initialized with its own copy of the skeleton document. Placeholders can also be defined to insert dynamic text into the document copy.

Placeholder expressions

Document models can define placeholder expressions that can be used to insert dynamic values into documents.

A placeholder definition consists of a key (which will be referenced from the document) and an expression that will be evaluated to give the corresponding value:

The expression will be applied at the time that the placeholders are updated, i.e. either when the document is first created from the document model or when the Update placeholders action is used subsequently.

Referencing placeholders from a Microsoft Word document

In a Microsoft word document, placeholders may be referenced by inserting a form field into the document with a Bookmark name that corresponds to the placeholder key:

Referencing placeholders from an Adobe PDF document

In a PDF document, placeholders may be referenced by inserting a form field into the document with a name that corresponds to the placeholder key:

A suitable PDF editing tool is required to create PDF documents with form fields.

Microsoft Word Mailing support

Microsoft Word documents support mailings functionality. Mailings fields can be replaced in a similar way as placeholders with document variable values. The fields have to be encapsulated into TableStart/End tags (Mailings regions support). variableName tag is replaced by variable value on update placeholders action.

To read more about merge mails follow the links: http://www.aspose.com/docs/display/wordsnet/Mail+Merge+with+Regions+Explained and http://support.microsoft.com/kb/212034.

3.2.4. Process model

A process model allows a full BPMN 2.0 process execution model to be defined. As for form models a process model can be previewed or edited in the modeler using the Design action, and the process definition XML can also be downloaded. Process models allow modeler to specify process init and work forms.

3.2.5. Case model

A case model is used define a new type of case. A case serves as a container for other work objects and can be used to store shared context information for a given workflow.

When a new case is created, it is possible to start processes, create tasks or create documents and link these to the case automatically. It is also possible to define which processes, tasks and documents can be created. This behaviour is defined using the Browse view. This view allows the init and work forms to be selected, as well as setting the candidate groups and allowed actions.

3.2.6. Mail model

A mail model provides a template for mails that can be sent by a given workflow. The mail model contains the templates for mail subject and header, both of which can use edoras one backend expressions to fill in the template with dynamic information at the time that the mail is sent.

3.3. Working with models

3.3.1. Accessing the modeler dashboard

All users that are part of the modeler group will be able to access the modeler dashboard.

3.3.2. Importing App models

An App model can be imported into the system by creating a new App through the user interface, and then using the Import action within the app to upload and import a Zip file containing the models to be imported.

When models are imported, the model will be checked to see whether it is already present on the system. If it is not present, then it will be created in the current App. If it is already present within the current App then it will be updated from the import file. If it is already present but as part of a different App then an error will be shown.

If a new model is created from scratch it is assigned an unchangeable ID which is used to track the model across all systems where the model is installed, and it is this ID which is used to establish the relationship between the models on the system and the models in the import file.

If the Import as duplicate option is selected when an App is imported the models in the imported App will not be checked against the models already present. New models will be created that are unconnected with the originals. This can be useful for creating a completely new App, using an existing App as a starting point.

3.3.3. Models state

Models have a state which changes as the models are edited and deployed. The available states are:

Table 14. Model states
State	Applies to	Description
active	Models	No pending changes. The model is currently deployed on the system.
inactive	Models except App model	No pending changes. The model has been deactivated on the system.
pending	Models	The model contains changes that have not yet been deployed.
pending inactive	Models except App model	The model will be deactivated on the system when it it next deployed.

3.3.4. Deploying an App model

When an App model is deployed, the models within that App model will be checked for consistency. If a model has been deactivated but there are still references from other active models then it will not be possible to deploy the App model. If the models are consistent then they will be deployed and corresponding definitions will be created. The users of the system will then be able to access the new workflow in the user dashboard.

Note that work objects and processes may already exist that were created using older versions of the model. These will not automatically be updated to use the new definitions: they will continue to use the definitions that were valid when they were created and will therefore not behave any differently after the new deployment.

3.3.5. Moving models between App models

All of the basic model types can be moved to another App as long as there are no outstanding references within the App model that it is being moved from.

3.3.6. Duplicating App models

All basic model types can also be duplicated, making an exact copy with a new name. This can be very useful when several small variations of a complex model are required.

Models may also be shared with different groups. By default all new models are shared with the modeler group, but in some circumstances it may be required for particular users to work on a particular set of models.

3.3.8. The System App

The administrator will also be able to see the System app in the modeler dashboard in addition to the App models that can be seen by normal modeler users. This App model contains a number of models that are required by the edoras one application and should normally not be changed.

3.4. Actions

Certain models are used to create user work items (e.g. Case, Task, Document). When created, the work item action toolbar (on the right hand side) will contain the actions that can be performed on the work item.

Which actions are available to the user depends on a number of factors:

the actions allowed by the model itself
the state of the work item
the user’s permissions

Some constraints are defined by edoras one itself and cannot be changed, but the model plays a large role in defining the available actions, and this should be considered carefully when designing a workflow.

To change the allowed actions, select the Browse view and add or remove actions as required in the Allowed Actions field:

Table 15. Actions
Action	Case	Task	Document	Description
Activate	Yes	Yes	Yes	Re-activate an archived work item
Archive	Yes*	No	Yes	Archived and active work item.
Assign	Yes	Yes	Yes	Change the work item’s owner / responsible
Create variables	Yes	Yes	Yes	Allow new variables to be created in the work item admin view
Download	No	No	Yes	Download the work item content
Download Pdf	No	No	Yes	Download the document in pdf format
Edit document	No	No	Yes	Edit the document
Move	No	No	Yes	Move the work item to another case
Preview	No	Yes	No	Show a work item preview
Share	Yes	Yes	Yes	Share the work item with specific groups
Start process	Yes	No	No	Start a new process instance
Update placeholders	No	No	Yes	Upload a new document
Upload document	No	No	Yes	Upload a new document

*There are three possibilities to archive cases which are displayed in the following table:

Table 16. Archive options for cases
Option Name	Description
Archive only if there are no active children	If case contains active processes, tasks or documents archive action returns an error.
Archive only if there are only active documents	If case contains active processes or tasks archive action returns an error. Active documents are archived automatically.
Archive the case and all children	Active processes and tasks are interrupted and it is not possible to activate them again. Active documents are archived.

3.5. Form palette

This section describes the elements available in the form palette of edoras one. Each modelling element and it’s corresponding attributes are described in detail below.

3.5.1. Concepts

This section describes the form concepts in edoras one. It starts with a description of how the layout of forms and fields works in edoras one. Then it describes how a form and its fields are bound to the data model.

Form layout

A form is a graphical layout of fields that may be bound to a data model to allow this data model to be displayed to the user. The fields are arranged in rows.

Figure 2. Form layout

Each row is made up of exactly twelve slots. All slots are equal in size, so the width of a slot is one twelfth the width of the whole form. A field can occupy exactly all slots or it can occupy only a part of the slots. With this it is possible to place more than one field in a row.

Figure 3. Form layout with slots

Not every slot needs to be occupied by a field. It is allowed that single slots of a row are empty. These empty slots can be at the beginning, in the middle, or at the end of a row.

Figure 4. Form layout with empty slots

Field layout

A field is made up of several parts (all but the widget part are optional):

widget: The widget visualizes the data model. Most widgets are interactive and let the user change the data model, however some widgets are read-only. There are widgets to manipulate strings, numbers, dates, rich text, selections, and many others. The widget is located in the center of the field, all other parts are arranged around the widget. The field configuration defines the concrete positioning of the field parts.
Label: The label tells the user to which part of the data model the widget is bound. The label is located on the left side or on top of the widget (depends on the field configuration).
Required indicator: The required indicator is displayed for required fields. Required means that the widget cannot be empty. The required indicator is located on the right side of the widget.
Description: The description gives additional information to the user. This can be formatting instructions or further description about how the App uses the entered value. The description is located on the bottom of the widget.

Figure 5. Field layout

Field alignment

To enhance the readability of a form, the field parts of all fields are aligned among themselves: the labels are aligned, the widgets and descriptions are aligned, the required indicators are aligned.

The alignment is performed per slot. All fields that start in the same slot build a field group. Inside such a field group edoras one looks for the widest label which becomes the dominating label for that slot. All labels in the field group are then enlarged to the same width of the dominating label. This is done by adding empty space between the label and the widget. This ensures that all widgets and descriptions of a field group start in one line and all.

Figure 6. Field alignment

The only exception is with fields that have top label position. For these fields the label, the widget and the description all start at the beginning of the slot.

Figure 7. Field alignment with top label position

Binding

Binding is the process to connect the form fields to the data model. The binding in edoras one is always two-way. When the user changes the form fields then those changes are immediately propagated to the data model. On the other side changes in the data model are immediately propagated back to the form fields.

A binding expression defines to which part of the data model the form field is connected. The binding expression has to be a writable frontend expression, e.g. {{foo}}, {{case.bar}}.

There are some reserved expressions which can not be used as they are used internally to save some work item information. They are:

id
definitionId
definition
type
state
creationTime
updateTime
currentUser

Moreover the expressions referring to the hierarchy (e.g. root, parent) can be only be used in order to bind nested widgets like subforms.

3.5.2. Common attributes

There are several attributes that are available for all form widgets. These common attributes define the rendering and the layout of the form field, as well as the part of the data model to which the form field is bound.

Attribute name	Description
Label	The label is a single word or term that describes the purpose of the form widget. When the form is rendered, the label is located either on the left side or on top of the widget (depends on the value of the Label position attribute). Typical labels are: First name, Last name, Sex, Address, ZIP code, City. Labels can be localized. See Localization to learn how to localize your Apps.
Label position	The label position relative to the widget, can be either Left or Top.
Value	The value connects the form field to the data model. As such the value decides which part of the data model the form field visualizes and which part of the data model is updated when the user interacts with the widget. See Binding to learn how binding in edoras one works.
Default value	The default value is the value that is applied when the data model is undefined, i.e. not yet initialized. The default value can be expressed as a static value or as a frontend expression. Typical default values are: Support (= string), false (= boolean), 42 (= number), Comment from {{role}} (= frontend expression). See Frontend expressions to learn the frontend expression syntax.
Description	The description is a whole sentence that describes the purpose of the form widget in more detail. When the form is rendered, the description is located below the widget. A typical description is: The ZIP file format is ##, e.g 4143. The ZIP is used to lookup the city. Descriptions can be localized. See Localization to learn how to localize your Apps.
Documentation	Intended for documenting details about specific widget to explain concepts of its use for future reference.
Visible	The visible flag decides if the form field is shown or hidden. If true, the form field is shown, if false the form field is hidden. The visible flag is a runtime value which means you can configure a frontend expression for it. A typical frontend expression for the visible flag is: {{case.showDeliveryAddress}} See Frontend expressions to learn the frontend expression syntax.
Editable	The editable flag decides if the form widget is editable or read-only. If true, the user can manipulate the form widget to change the data model, if false the user is not able to change the data model. The editable flag is a runtime value which means you can configure a frontend expression for it. A typical frontend expression for the editable flag is: {{case.step1Completed}} See Frontend expressions to learn the frontend expression syntax.
Style class	The style class allows to add additional CSS styles to the form field.

Attribute name

Description

Label

The label is a single word or term that describes the purpose of the form widget. When the form is rendered, the label is located either on the left side or on top of the widget (depends on the value of the Label position attribute).

Typical labels are: First name, Last name, Sex, Address, ZIP code, City.

Labels can be localized. See Localization to learn how to localize your Apps.

Label position

The label position relative to the widget, can be either Left or Top.

Value

The value connects the form field to the data model. As such the value decides which part of the data model the form field visualizes and which part of the data model is updated when the user interacts with the widget.

See Binding to learn how binding in edoras one works.

Default value

The default value is the value that is applied when the data model is undefined, i.e. not yet initialized. The default value can be expressed as a static value or as a frontend expression.

Typical default values are: Support (= string), false (= boolean), 42 (= number), Comment from {{role}} (= frontend expression).

See Frontend expressions to learn the frontend expression syntax.

Description

The description is a whole sentence that describes the purpose of the form widget in more detail. When the form is rendered, the description is located below the widget.

A typical description is: The ZIP file format is ##, e.g 4143. The ZIP is used to lookup the city.

Descriptions can be localized. See Localization to learn how to localize your Apps.

Documentation

Intended for documenting details about specific widget to explain concepts of its use for future reference.

Visible

The visible flag decides if the form field is shown or hidden. If true, the form field is shown, if false the form field is hidden. The visible flag is a runtime value which means you can configure a frontend expression for it.

A typical frontend expression for the visible flag is: {{case.showDeliveryAddress}}

See Frontend expressions to learn the frontend expression syntax.

Editable

The editable flag decides if the form widget is editable or read-only. If true, the user can manipulate the form widget to change the data model, if false the user is not able to change the data model. The editable flag is a runtime value which means you can configure a frontend expression for it.

A typical frontend expression for the editable flag is: {{case.step1Completed}}

See Frontend expressions to learn the frontend expression syntax.

Style class

The style class allows to add additional CSS styles to the form field.

3.5.3. Validation attributes

A validation method checks if a widget contains valid data, if not edoras one displays an error message that instructs the user how to fix his input. edoras one supports many different validation methods, not all are available for all form widgets.

Validation is only done if the user is able to fix a potential validation error. This is not the case for hidden and read-only form fields, so such fields are not validated.

The following table lists the supported validation methods.

Attribute name	Description
Required	The required flag defines if a form field can be empty or not. If true then the form field is not allowed to be empty, if false the form field might be empty. A typical sample where the required flag is set to true is a name field that is mandatory. The following form widgets support the required flag: text, text area, rich text area, password, number, date, checkbox, autocomplete, select, radio buttons.
Minimum length	The minimum length validation ensures that the text input is longer than a minimum length. A typical sample is a password that has to be at least 4 characters long. The following form widgets support the minimum length validation: text, text area, rich text area, password. The Minimum length error message attribute holds the error message that is displayed when the text input is less than the configured number of characters.
Maximum length	The maximum length validation ensures that the text input has a smaller than a maximum length. A typical sample is a password that has to be at most 8 characters long. The following form widgets support the minimum length validation: text, text area, rich text area, password. The Maximum length error message attribute holds the error message that is displayed when the text input is bigger than the configured number of characters.
Regular expression	The regular expression validation ensures that the text input matches a regular expression. See http://www.w3schools.com/jsref/jsref_obj_regexp.asp for more information on the supported regular expression syntax. Regular expression can be become quite complex and difficult to understand. http://www.regular-expressions.info/javascriptexample.html provides a good way to test your regular expressions. A typical sample is the number of a credit card which matches: ^4[0-9]{11,12}(?:[0-9]{3})?$. The following form widgets support the regular expression validation: text, text area, rich text area, password. The Regular expression error message attribute holds the error message that is displayed when the text input does not match the regular expression.
Mask	The mask validation ensures that the text input adhere to a certain pattern. The mask can contain the following special characters: * a - Represents an alpha character (A-Z,a-z) * 9 - Represents a numeric character (0-9) * * - Represents an alphanumeric character (A-Z,a-z,0-9) * all other characters are treated as fixed input A typical sample is the expiry date of a credit card which is the month followed by a dash followed by the year. The mask that adheres to this pattern is 99/9999. The text form widget supports mask validation. The Mask error message attribute holds the error message that is displayed when the text input does not match the mask.
Minimum	The minimum validation ensures that the number input is equals to or bigger than a minimum. A typical sample is an order quantity field which has to be equals to or bigger than 1. The number form widget supports the minimum validation. The Minimum error message attribute holds the error message that is displayed when the number input is less than the configured minimum. The minimum number supported is -9007199254740991.
Maximum	The maximum validation ensures that the number input is equals to or less than a maximum. A typical sample is an order quantity field which has to be equals to or lower than 100. The number form widget supports the minimum validation. The Maximum error message attribute holds the error message that is displayed when the number input is bigger than the configured maximum. The maximum number supported is 9007199254740991.
Minimum date	The minimum date validation ensures that the date input is equals to or after a minimum date. The minimum date can be a fixed date, today, or a day relative to today. A typical sample is an delivery date field which has to be equals to or after today. The date form widget supports the minimum date validation. The Minimum date error message attribute holds the error message that is displayed when the date input is before the configured minimum date.
Maximum date	The maximum date validation ensures that the date input is equals to or before a maximum date. The maximum date can be a fixed date, today, or a day relative to today. A typical sample is a birthday field which has to be equals to or before today. The date form widget supports the maximum date validation. The Maximum date error message attribute holds the error message that is displayed when the date input is after the configured maximum.
Invalid selection error message	This validation displays an error message when the selection input is not available anymore. The autocomplete and the select widgets support the invalid selection validation. Both form widgets look up if the selection is in the available options to check if the selection is valid or not.
Minimum number of elements	The minimum number of elements validation ensures that the input contains at least a certain number of elements. A typical sample is an order which has to contain at least one order position. The subform widget and the autocomplete widget with multi-selection supports the minimum number of elements validation. The Minimum number of elements error message attribute holds the error message that is displayed when the input contains less than the configured number of elements.
Maximum number of elements	The maximum number of elements validation ensures that the input contains at most a certain number of elements. A typical sample is a wish list which can hold at most ten wishes. The subform widget and the autocomplete widget with multi-selection supports the maximum number of elements validation. The Maximum number of elements error message attribute holds the error message that is displayed when the input contains more than the configured number of entries.
Minimum number of attachments	The minimum files validation ensures that not less than a certain number of files are attached. A typical sample is a support incident attachment field where at lease one screenshot has to be attached. The attachment form widget supports the minimum files validation. The Minimum number of attachments error message attribute holds the error message that is displayed when the attachment input has less files attached than the configured number.
Maximum number of attachments	The maximum files validation ensures that at not more than a certain number of files are attached. A typical sample is a favourite images attachment field where not more than ten images can be attached. The attachment widget supports the maximum files validation. The Maximum number of attachments error message attribute holds the error message that is displayed when the attachment input has more files attached than the configured number.
Minimum number of rows	The minimum number of rows validation ensures that not less than a certain number of rows are displayed. A typical sample is a list which has always the same name of rows even they are empty. The list form widget supports the minimum number of rows validation.
Maximum number of rows	The maximum number of rows validation ensures that at not more than a certain number of rows are displayed. A typical sample is a wish list which can hold at most ten wishes. The list form widget supports the maximum number of rows validation.

Attribute name

Description

Required

The required flag defines if a form field can be empty or not. If true then the form field is not allowed to be empty, if false the form field might be empty.

A typical sample where the required flag is set to true is a name field that is mandatory.

The following form widgets support the required flag: text, text area, rich text area, password, number, date, checkbox, autocomplete, select, radio buttons.

Minimum length

The minimum length validation ensures that the text input is longer than a minimum length.

A typical sample is a password that has to be at least 4 characters long.

The following form widgets support the minimum length validation: text, text area, rich text area, password.

The Minimum length error message attribute holds the error message that is displayed when the text input is less than the configured number of characters.

Maximum length

The maximum length validation ensures that the text input has a smaller than a maximum length.

A typical sample is a password that has to be at most 8 characters long.

The following form widgets support the minimum length validation: text, text area, rich text area, password.

The Maximum length error message attribute holds the error message that is displayed when the text input is bigger than the configured number of characters.

Regular expression

The regular expression validation ensures that the text input matches a regular expression. See http://www.w3schools.com/jsref/jsref_obj_regexp.asp for more information on the supported regular expression syntax. Regular expression can be become quite complex and difficult to understand. http://www.regular-expressions.info/javascriptexample.html provides a good way to test your regular expressions.

A typical sample is the number of a credit card which matches: ^4[0-9]{11,12}(?:[0-9]{3})?$.

The following form widgets support the regular expression validation: text, text area, rich text area, password.

The Regular expression error message attribute holds the error message that is displayed when the text input does not match the regular expression.

Mask

The mask validation ensures that the text input adhere to a certain pattern. The mask can contain the following special characters: * a - Represents an alpha character (A-Z,a-z) * 9 - Represents a numeric character (0-9) * * - Represents an alphanumeric character (A-Z,a-z,0-9) * all other characters are treated as fixed input

A typical sample is the expiry date of a credit card which is the month followed by a dash followed by the year. The mask that adheres to this pattern is 99/9999.

The text form widget supports mask validation.

The Mask error message attribute holds the error message that is displayed when the text input does not match the mask.

Minimum

The minimum validation ensures that the number input is equals to or bigger than a minimum.

A typical sample is an order quantity field which has to be equals to or bigger than 1.

The number form widget supports the minimum validation.

The Minimum error message attribute holds the error message that is displayed when the number input is less than the configured minimum.

The minimum number supported is -9007199254740991.

Maximum

The maximum validation ensures that the number input is equals to or less than a maximum.

A typical sample is an order quantity field which has to be equals to or lower than 100.

The number form widget supports the minimum validation.

The Maximum error message attribute holds the error message that is displayed when the number input is bigger than the configured maximum.

The maximum number supported is 9007199254740991.

Minimum date

The minimum date validation ensures that the date input is equals to or after a minimum date. The minimum date can be a fixed date, today, or a day relative to today.

A typical sample is an delivery date field which has to be equals to or after today.

The date form widget supports the minimum date validation.

The Minimum date error message attribute holds the error message that is displayed when the date input is before the configured minimum date.

Maximum date

The maximum date validation ensures that the date input is equals to or before a maximum date. The maximum date can be a fixed date, today, or a day relative to today.

A typical sample is a birthday field which has to be equals to or before today.

The date form widget supports the maximum date validation.

The Maximum date error message attribute holds the error message that is displayed when the date input is after the configured maximum.

Invalid selection error message

This validation displays an error message when the selection input is not available anymore.

The autocomplete and the select widgets support the invalid selection validation.

Both form widgets look up if the selection is in the available options to check if the selection is valid or not.

Minimum number of elements

The minimum number of elements validation ensures that the input contains at least a certain number of elements.

A typical sample is an order which has to contain at least one order position.

The subform widget and the autocomplete widget with multi-selection supports the minimum number of elements validation.

The Minimum number of elements error message attribute holds the error message that is displayed when the input contains less than the configured number of elements.

Maximum number of elements

The maximum number of elements validation ensures that the input contains at most a certain number of elements.

A typical sample is a wish list which can hold at most ten wishes.

The subform widget and the autocomplete widget with multi-selection supports the maximum number of elements validation.

The Maximum number of elements error message attribute holds the error message that is displayed when the input contains more than the configured number of entries.

Minimum number of attachments

The minimum files validation ensures that not less than a certain number of files are attached.

A typical sample is a support incident attachment field where at lease one screenshot has to be attached.

The attachment form widget supports the minimum files validation.

The Minimum number of attachments error message attribute holds the error message that is displayed when the attachment input has less files attached than the configured number.

Maximum number of attachments

The maximum files validation ensures that at not more than a certain number of files are attached.

A typical sample is a favourite images attachment field where not more than ten images can be attached.

The attachment widget supports the maximum files validation.

The Maximum number of attachments error message attribute holds the error message that is displayed when the attachment input has more files attached than the configured number.

Minimum number of rows

The minimum number of rows validation ensures that not less than a certain number of rows are displayed.

A typical sample is a list which has always the same name of rows even they are empty.

The list form widget supports the minimum number of rows validation.

Maximum number of rows

The maximum number of rows validation ensures that at not more than a certain number of rows are displayed.

A typical sample is a wish list which can hold at most ten wishes.

The list form widget supports the maximum number of rows validation.

3.5.4. Text form widgets

The text form widgets allow the user to input text. To support different text input requirements edoras one provides different text form widget variants. The following list explains the different text form widget variants:

Form widget	Description
	Used to input a single line of regular text.
	Used to input multiple lines of regular text.
	Used to input multiple lines of rich text. In contrast to regular text, rich text can be formatted in various ways: regular, bold, italic, ordered list, unordered list, headings, and much more.
	Used to input a password. The password form widget is marked with a small key icon at the right border of the widget. To hide the typed text from curious people all typed characters are visualized as dots.
	Used to input an integral number. The integral number form widget is marked with a small hash icon at the right border of the widget. We should to be aware that Javascript number has a limited precision (64-bit binary format IEEE 754 value). It does not support a negative exponential notation like 1e-2 but can support positive exponential notation like 1e+2.
	Used to input an float number. The float number form widget is marked with a small hash icon at the right border of the widget. We should to be aware that Javascript number has a limited precision (64-bit binary format IEEE 754 value). So if, for example, we have a number with too many decimals, which cannot be represented, it will be rounded.
	Used to input a date. The date form widget is marked with a small calendar icon at the right border of the control. All non date input is treated as invalid. The user can enter a date in two ways. First he can enter the date as date string, e.g. 1970-11-25. Second he can use a date picker to select a date with the mouse. The date picker pops up as soon as the date control receives focus.

Form widget

Description

Used to input a single line of regular text.

Used to input multiple lines of regular text.

Used to input multiple lines of rich text.

In contrast to regular text, rich text can be formatted in various ways: regular, bold, italic, ordered list, unordered list, headings, and much more.

Used to input a password.

The password form widget is marked with a small key icon at the right border of the widget. To hide the typed text from curious people all typed characters are visualized as dots.

Used to input an integral number.

The integral number form widget is marked with a small hash icon at the right border of the widget.

We should to be aware that Javascript number has a limited precision (64-bit binary format IEEE 754 value).

It does not support a negative exponential notation like 1e-2 but can support positive exponential notation like 1e+2.

Used to input an float number.

The float number form widget is marked with a small hash icon at the right border of the widget.

We should to be aware that Javascript number has a limited precision (64-bit binary format IEEE 754 value). So if, for example, we have a number with too many decimals, which cannot be represented, it will be rounded.

Used to input a date.

The date form widget is marked with a small calendar icon at the right border of the control. All non date input is treated as invalid.

The user can enter a date in two ways. First he can enter the date as date string, e.g. 1970-11-25. Second he can use a date picker to select a date with the mouse. The date picker pops up as soon as the date control receives focus.

Text attributes

Attribute	Description
Common	See Common attributes to learn more about the common attributes.
Validation	The text form widget supports the required, the minimum length, the maximum length, the regular expression, and the mask validation. See Validation attributes to learn more about validation.

Attribute

Description

Common

See Common attributes to learn more about the common attributes.

Validation

The text form widget supports the required, the minimum length, the maximum length, the regular expression, and the mask validation.

See Validation attributes to learn more about validation.

Text area attributes

Attribute	Description
Common	See Common attributes to learn more about the common attributes.
Validation	The text area form widget supports the required, the minimum length, and the maximum length validation. See Validation attributes to learn more about validation.

Attribute

Description

Common

See Common attributes to learn more about the common attributes.

Validation

The text area form widget supports the required, the minimum length, and the maximum length validation.

See Validation attributes to learn more about validation.

Rich text area attributes

Attribute	Description
Common	See Common attributes to learn more about the common attributes. The Default value attribute of a Rich text area form widget is rich text which supports the following formatting options (see toolbar buttons on top of the default value editor): bold, italic, and underline text style font size foreground and background color left, center, and right text alignment headline, sub-headline, and section headline style ordered and unordered list text indentation horizontal line links
Validation	The rich text area form widget supports the required, the minimum length, and the maximum length validation. See Validation attributes to learn more about validation.

Attribute

Description

Common

See Common attributes to learn more about the common attributes.

The Default value attribute of a Rich text area form widget is rich text which supports the following formatting options (see toolbar buttons on top of the default value editor):

bold, italic, and underline text style
font size
foreground and background color
left, center, and right text alignment
headline, sub-headline, and section headline style
ordered and unordered list
text indentation
horizontal line
links

Validation

The rich text area form widget supports the required, the minimum length, and the maximum length validation.

See Validation attributes to learn more about validation.

Password attributes

Attribute	Description
Common	See Common attributes to learn more about the common attributes.
Validation	The password form widget supports the required, the minimum length, and the maximum length validation. See Validation attributes to learn more about validation.

Attribute

Description

Common

See Common attributes to learn more about the common attributes.

Validation

The password form widget supports the required, the minimum length, and the maximum length validation.

See Validation attributes to learn more about validation.

Integral number attributes

Attribute	Description
Common	See Common attributes to learn more about the common attributes. *Default property: it only supports a frontend expression or an integral number without format.
Validation	The number form widget supports the required, the minimum, and the maximum validation. The maximum value for a number is 9007199254740991. The minimum value for a number is -9007199254740991. See Validation attributes to learn more about validation.
Format	Defines the format of the number with thousand and decimal separators. "No format" will not apply any format. Format "auto" will apply the format depending on the language of the current user. With Format "auto", if the language is English, it will apply "1,000,000" format. With Format "auto", if the language is Spanish, German or Italian it will apply "1.000.000" format. With Format "auto", if the language is French, it will apply "1 000 000" format.

Attribute

Description

Common

See Common attributes to learn more about the common attributes.

*Default property: it only supports a frontend expression or an integral number without format.

Validation

The number form widget supports the required, the minimum, and the maximum validation.

The maximum value for a number is 9007199254740991. The minimum value for a number is -9007199254740991.

See Validation attributes to learn more about validation.

Format

Defines the format of the number with thousand and decimal separators. "No format" will not apply any format.

Format "auto" will apply the format depending on the language of the current user. With Format "auto", if the language is English, it will apply "1,000,000" format. With Format "auto", if the language is Spanish, German or Italian it will apply "1.000.000" format. With Format "auto", if the language is French, it will apply "1 000 000" format.

Float number attributes

Attribute	Description
Common	See Common attributes to learn more about the common attributes. *Default property: it only supports a frontend expression or a number without format.
Validation	The float number form widget supports the required, the minimum, and the maximum validation. The maximum value for a number is 9007199254740991. The minimum value for a number is -9007199254740991. See Validation attributes to learn more about validation.
Fraction size	Defines the maximum number of decimal characters for float type. If fraction size is bigger than 0, exponential notation is not supported. If fraction size is 0, it will behave like integer number widget.
Format	Defines the format of the number with thousand and decimal separators. "No format" will not apply any format. Format "auto" will apply the format depending on the language of the current user. With Format "auto", if the language is English, it will apply "1,000,000.22" format. With Format "auto", if the language is Spanish, German or Italian it will apply "1.000.000,22" format. With Format "auto", if the language is French, it will apply "1 000 000,22" format.

Attribute

Description

Common

See Common attributes to learn more about the common attributes.

*Default property: it only supports a frontend expression or a number without format.

Validation

The float number form widget supports the required, the minimum, and the maximum validation.

The maximum value for a number is 9007199254740991. The minimum value for a number is -9007199254740991.

See Validation attributes to learn more about validation.

Fraction size

Defines the maximum number of decimal characters for float type.

If fraction size is bigger than 0, exponential notation is not supported. If fraction size is 0, it will behave like integer number widget.

Format

Defines the format of the number with thousand and decimal separators. "No format" will not apply any format.

Format "auto" will apply the format depending on the language of the current user. With Format "auto", if the language is English, it will apply "1,000,000.22" format. With Format "auto", if the language is Spanish, German or Italian it will apply "1.000.000,22" format. With Format "auto", if the language is French, it will apply "1 000 000,22" format.

Date attributes

Attribute	Description
Common	See Common attributes to learn more about the common attributes. The default value of a date field form field can be specified as absolute date, as relative date, or as frontend expression.
Validation	The date form widget supports the required, the minimum date, and the maximum date validation. See Validation attributes to learn more about validation.
Format	Used to define the format in which the date is visualized to the user. If empty then the date is presented in the ISO 8601 format, e.g. 1970-11-25. See Formatting dates in frontend expressions to learn more about the possible format strings.
Number of visible years	Used to define the range of years displayed in the year drop-down.

Attribute

Description

Common

See Common attributes to learn more about the common attributes.

The default value of a date field form field can be specified as absolute date, as relative date, or as frontend expression.

Validation

The date form widget supports the required, the minimum date, and the maximum date validation.

See Validation attributes to learn more about validation.

Format

Used to define the format in which the date is visualized to the user. If empty then the date is presented in the ISO 8601 format, e.g. 1970-11-25.

See Formatting dates in frontend expressions to learn more about the possible format strings.

Number of visible years

Used to define the range of years displayed in the year drop-down.

3.5.5. Select form widgets

The select form widgets allow the user to select one or more options from a potential large set of options. The available options are presented in a list from which the user can select one or more options with help of the keyboard and the mouse.

Some select form widget support the filtering of the available options. When the user starts typing then only the options that match the typed text are presented as available options. This makes it easy to locate a specific option in a large set of options.

The select form widgets are very powerful form widgets. To support different selection requirements edoras one provides different variants of select form widgets. The following list explains these variants:

Selection	Options	Description
Single	Boolean true/false	Used to select a simple yes/no option. When the checkbox is ticked then true is stored in the data model, otherwise false is stored in the data model.
Single	Static options	Used to select a single option from a static list of options. At design time the modeler configures for each option a name and a value. The name is displayed to the user whereas the value is stored in the data model. In the radio button form widget all options are always visible. With this the user can always see all possible option, on the other side this uses a lot of form real estate and is therefore suited only it there are few options.
Single or multiple	JSON options	Used to select one or more options from a dynamic list of options. The dynamic list of options is built at runtime by calling a custom REST endpoint that the modeler has configured. Either a single attribute of the option or the complete option is stored in the data model.
Single or multiple	edoras one work items	Used to select one or more work items from a dynamic list of work items. The dynamic list of work items is built at runtime by calling edoras one with a query that the modeler has configured. Either the work item id or the complete work item is stored in the data model.
Single or multiple	Static options	Used to select one or more options from a static list of options. At design time the modeler configures for each option a name and a value. The name is displayed to the user whereas the value is stored in the data model.
Single	Static options	Used to select a single option from a static list of options. At design time the modeler configures for each option a name and a value. The name is displayed to the user whereas the value is stored in the data model. The select static form widget is not able to filter the possible options. To select an option the user first has to navigate to the desired option by scrolling in the option list. Therefore this form widget is not a good choice if there is a large number of options.

Form widget

Selection

Options

Description

Single

Boolean true/false

Used to select a simple yes/no option.

When the checkbox is ticked then true is stored in the data model, otherwise false is stored in the data model.

Single

Static options

Used to select a single option from a static list of options.

At design time the modeler configures for each option a name and a value. The name is displayed to the user whereas the value is stored in the data model.

In the radio button form widget all options are always visible. With this the user can always see all possible option, on the other side this uses a lot of form real estate and is therefore suited only it there are few options.

Single or multiple

JSON options

Used to select one or more options from a dynamic list of options.

The dynamic list of options is built at runtime by calling a custom REST endpoint that the modeler has configured. Either a single attribute of the option or the complete option is stored in the data model.

Single or multiple

edoras one work items

Used to select one or more work items from a dynamic list of work items.

The dynamic list of work items is built at runtime by calling edoras one with a query that the modeler has configured. Either the work item id or the complete work item is stored in the data model.

Single or multiple

Static options

Used to select one or more options from a static list of options.

At design time the modeler configures for each option a name and a value. The name is displayed to the user whereas the value is stored in the data model.

Single

Static options

Used to select a single option from a static list of options.

At design time the modeler configures for each option a name and a value. The name is displayed to the user whereas the value is stored in the data model.

The select static form widget is not able to filter the possible options. To select an option the user first has to navigate to the desired option by scrolling in the option list. Therefore this form widget is not a good choice if there is a large number of options.

The functionality of the Radio button group, the Autocomplete static and the Select static form widgets is similar. The only difference is the look and feel. The Radio button group form widget always shows all options with the drawback that this requires a lot of form real estate. The Autocomplete static and the Select static form widgets need little form real estate with the drawback that the user first has to focus the field and open a popup to see the available options.

the functionality of the REST autocomplete select and the Autocomplete select form widgets is similar. The only difference is that the REST autocomplete select form widget uses a custom REST endpoint to load the possible options (which can be of any format) whereas the Autocomplete select form widget uses edoras one to load the possible work items.

Checkbox attributes

Attribute name	Description
Common	See Common attributes to learn more about the common attributes.
Validation	The checkbox form widget supports the required validation. See Validation attributes to learn more about validation.

Attribute name

Description

Common

See Common attributes to learn more about the common attributes.

Validation

The checkbox form widget supports the required validation.

See Validation attributes to learn more about validation.

Radio button group attributes

Attribute name	Description
Common	See Common attributes to learn more about the common attributes.
Validation	The radio button group form widget supports the required validation. See Validation attributes to learn more about validation.
Options	Defines the options from which the user can choose. Each option has a name and a value: the name is shown to the user whereas the value is stored in the data model.
Orientation	Defines if the single radio buttons in the group are Horizontal or Vertical aligned.

Attribute name

Description

Common

See Common attributes to learn more about the common attributes.

Validation

The radio button group form widget supports the required validation.

See Validation attributes to learn more about validation.

Options

Defines the options from which the user can choose. Each option has a name and a value: the name is shown to the user whereas the value is stored in the data model.

Orientation

Defines if the single radio buttons in the group are Horizontal or Vertical aligned.

formComponentRadioButtonGroupRuntimeVertical

REST autocomplete select attributes

Attribute name

Description

Common

See Common attributes to learn more about the common attributes.

Validation

The REST autocomplete select form widget supports the following validations:

Required.
Invalid selection.
Minimum number of elements.
Maximum number of elements.

See Validation attributes to learn more about validation.

Query URL

Used to load the available options that are presented to the user from a URL.

The query URL attribute can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax.

The autocomplete form widget expects the options to be returned as list of JSON objects, e.g.

[ {
  "id" : "GEAR-a65c4a12-20b4-45d8-bb09-2105be7f0d1f",
  "title" : "edoras one Modeler",
  "value" : "GEAR-a65c4a12-20b4-45d8-bb09-2105be7f0d1f"
}, {
  "id" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac",
  "title" : "edoras one User",
  "value" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac"
} ]

The user typed text is added as a URL parameter to the query URL.

https://one.edorasware.com/rest/one-groups?typedText=edoras

Usually the REST endpoint uses the typed text to filter the available options. This way the user sees only the options that match the already typed text and can easily locate single options in a large set of options.

The options are filtered in the REST endpoint and not in the autocomplete form widget. If the REST endpoint does not do the filtering then independent of the typed text the autocomplete form widget always presents the same options to the user.

Referencing external resources may have problems due to SSL (https) or CORS security browser limitations. To solve CORS security, the resource server must send appropriate response headers. Another option is using a proxy to receive the right response headers from any url e.g .:https://cors-anywhere.herokuapp.com. To solve SSL if edoras one is being executed over https, the url of the external resource should also have the https protocol.

Lookup URL

Used for two things:

first: to load the complete information of the selected options (only if they are stored in serialized form in the data model)
second: to validate if the selected options are still available, see Validation attributes to learn more about this validation

In both cases the serialized option is appended to the lookup URL, e.g.

https://one.edorasware.com/rest/one-groups/GEAR-a65c4a12-20b4-45d8-bb09-2105be7f0d1f

The option is serialized with help of the Serialization. So the Lookup URL and the Serialization attribute have to play together.

Serialization

Used to select the attribute in the JSON option that is stored in the data model.

The prefix to select an attribute from the JSON option is item.

So if the JSON option looks like

{
  "id" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac",
  "title" : "edoras one User",
  "value" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac"
}

then a Serialization of item.id results in GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac being stored in the data model.

Please note that the Serialization, the Query URL, and the Lookup URL attributes have to play together. The Serialization converts the JSON options returned by the Query URL REST endpoint into strings which then are stored in the data model. And the Lookup URL REST endpoint does the opposite: it takes the strings stored in the data model and converts them back into JSON options.

Format

Used to compose a user friendly string from the JSON option.

The prefix to select an attribute from the JSON option is item. Literals have to be enclosed in quotes, attributes and literals can be concatenated with +.

So if the JSON option looks like

{
  "id" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac",
  "title" : "edoras one User",
  "value" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac"
}

then a format of Group: {{item.title}} results in Group: edoras one User being presented to the user for this JSON option.

Navigation URL

Used to set a link icon to the left of each option in the list and each selected option. The Navigation URL defines the URL to navigate to when the user clicks a link icon.

The navigation URL attribute can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax.

The prefix to select an attribute from the JSON option is $item.

So if the JSON option looks like

{
  "id" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac",
  "title" : "edoras one User",
  "value" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac"
}

then a navigation URL of /GRP/{{$item.id}}/browse results in /GRP/GEAR-3456061f-4892-4ef4-b234-69217201cd09/browse being invoked when the user clicks the link icon.

Target

Used to define the tab where the linked option is loaded.

Possible values are:

_blank ⇒ Load in a new tab
_self ⇒ Load in the same tab as it was clicked
tabname ⇒ Load in a named tab, if there is no tab with that name then a new tab is created with that name

Multi selection

False if only one option can be selected, true if multiple options can be selected.

If true then the selected options are stored as a list in the data model.

formComponentAutocompleteRuntimeMultiple

Preselect all

If true, ALL objects returned by the REST endpoint are automatically selected. This only works, if multi selection is turned on too.

Autocomplete select attributes

Attribute name	Description
Common	See Common attributes to learn more about the common attributes.
Validation	The autocomplete select form widget supports the following validations: Required. Invalid selection. Minimum number of elements. Maximum number of elements. See Validation attributes to learn more about validation.
Query	The edoras one query that is used to load the available work items that are presented to the user. The user typed text is added as additional filter to the configured query. Typical queries: type:CAS for:me all cases that are assigned to me type:TSK for:me,unassigned all tasks that are either directly assigned to me or are unassigned type:CAS app:foo all cases that belong to the foo App See section Searches in the User guide to learn more about the search syntax and about all possible search terms.
Format	Used to compose a user friendly string from the work item. The prefix to select an variable from the work item item. Literals have to be enclosed in quotes, attributes and literals can be concatenated with +. So if the format is Group: {{item.name}} then the work item is shown to the user as Group: edoras one User.
Navigation view	Used to set the target view for the link. Possible values are: Browse ⇒ The link points to the form view of the work item Preview ⇒ The link points to the preview view of the work item
Target	Used to define the tab where the linked work item is loaded. Possible values are: _blank ⇒ Load in a new tab _self ⇒ Load in the same tab as it was clicked tabname ⇒ Load in a named tab, if there is no tab with that name then a new tab is created with that name
Multi selection	False if only one option can be selected, true if multiple options can be selected. If true then the selected options are stored as a list in the data model.
Preselect all	If true, ALL objects returned by the query are automatically selected. This only works, if multi selection is turned on too.

Attribute name

Description

Common

See Common attributes to learn more about the common attributes.

Validation

The autocomplete select form widget supports the following validations:

Required.
Invalid selection.
Minimum number of elements.
Maximum number of elements.

See Validation attributes to learn more about validation.

Query

The edoras one query that is used to load the available work items that are presented to the user.

The user typed text is added as additional filter to the configured query.

Typical queries:

type:CAS for:me: all cases that are assigned to me
type:TSK for:me,unassigned: all tasks that are either directly assigned to me or are unassigned
type:CAS app:foo: all cases that belong to the foo App

See section Searches in the User guide to learn more about the search syntax and about all possible search terms.

Format

Used to compose a user friendly string from the work item.

The prefix to select an variable from the work item item. Literals have to be enclosed in quotes, attributes and literals can be concatenated with +.

So if the format is Group: {{item.name}} then the work item is shown to the user as Group: edoras one User.

Navigation view

Used to set the target view for the link.

Possible values are:

Browse ⇒ The link points to the form view of the work item
Preview ⇒ The link points to the preview view of the work item

Target

Used to define the tab where the linked work item is loaded.

Possible values are:

_blank ⇒ Load in a new tab
_self ⇒ Load in the same tab as it was clicked
tabname ⇒ Load in a named tab, if there is no tab with that name then a new tab is created with that name

Multi selection

False if only one option can be selected, true if multiple options can be selected.

If true then the selected options are stored as a list in the data model.

Preselect all

If true, ALL objects returned by the query are automatically selected. This only works, if multi selection is turned on too.

Static autocomplete select attributes

Attribute name	Description
Common	See Common attributes to learn more about the common attributes.
Validation	The static autocomplete select form widget supports the following validations: Required. Invalid selection. Minimum number of elements. Maximum number of elements. See Validation attributes to learn more about validation.
Options	Defines the options from which the user can choose. Each option has a name and a value: the name is shown to the user whereas the value is stored in the data model.
Navigation URL	Used to set a link icon to the left of each option in the list and each selected option. The Navigation URL defines the URL to navigate to when the user clicks a link icon. The navigation URL attribute can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax. The prefix to select an attribute from the option is $item. The following two option attributes are available: name the name that is shown to the user value the value that is stored in the data model So if the navigation URL is https://www.google.ch/search?q={{$item.value}} then the link URL results in https://www.google.ch/search?q=edorasware.
Multi selection	False if only one option can be selected, true if multiple options can be selected. If true then the selected options are stored as a list in the data model.
Preselect all	Preselects all the available options. It only applies if no options are selected by default.

Attribute name

Description

Common

See Common attributes to learn more about the common attributes.

Validation

The static autocomplete select form widget supports the following validations:

Required.
Invalid selection.
Minimum number of elements.
Maximum number of elements.

See Validation attributes to learn more about validation.

Options

Defines the options from which the user can choose. Each option has a name and a value: the name is shown to the user whereas the value is stored in the data model.

Navigation URL

Used to set a link icon to the left of each option in the list and each selected option. The Navigation URL defines the URL to navigate to when the user clicks a link icon.

The navigation URL attribute can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax.

The prefix to select an attribute from the option is $item. The following two option attributes are available:

name: the name that is shown to the user
value: the value that is stored in the data model

So if the navigation URL is https://www.google.ch/search?q={{$item.value}} then the link URL results in https://www.google.ch/search?q=edorasware.

Multi selection

False if only one option can be selected, true if multiple options can be selected.

If true then the selected options are stored as a list in the data model.

Preselect all

Preselects all the available options. It only applies if no options are selected by default.

Static select attributes

Attribute name	Description
Common	See Common attributes to learn more about the common attributes.
Validation	The static select form widget supports the required and the invalid selection validation. See Validation attributes to learn more about validation.
Options	Defines the options from which the user can choose. Each option has a name and a value: the name is shown to the user whereas the value is stored in the data model.

Attribute name

Description

Common

See Common attributes to learn more about the common attributes.

Validation

The static select form widget supports the required and the invalid selection validation.

See Validation attributes to learn more about validation.

Options

Defines the options from which the user can choose. Each option has a name and a value: the name is shown to the user whereas the value is stored in the data model.

3.5.6. Read only form widgets

The read only form widgets allow to present information, to add navigation functionality, and to split a form into section.

Form widget	Description
	Used to show static rich text. The rich text can be formatted in various ways: regular, bold, italic, ordered list, unordered list, headings, and much more.
	Used to render html code.
	Used to show a list of options that are returned by a custom REST endpoint. The dynamic list of options is build at runtime by calling a custom REST endpoint that the modeler has configured. The rest list form widget can be used to enable simple navigation inside your App. For this the modeler can configure the links that are followed when the user clicks one of the options in the list.
	Used to show a list of work items that are returned by edoras one. The dynamic list of work items is build at runtime by calling calling edoras one with a query that the modeler has configured. The rest list form widget can be used to enable simple navigation inside your App. For this the modeler can configure the links that are followed when the user clicks one of the options in the list.
	Used to show an image.
	Used to show a generic link.
	A link which navigates to a specific initialization form for a new work item to be created based on a given model you can select in the work item model attribute
	Used to show a link that navigates to a list of work items returned by a search using a specified query.
	A link which renders a text including the numbers of elements returned by a count query you can specify. The link text can be configured to show the number of elements returned by the query. Clicking the link navigates to the result of the query.
	A link which renders a text including the numbers of elements returned by a REST endpoint. The link text can be configured to show the number of elements returned by the REST query. Clicking the link navigates to the result of the REST query.
	Used to show a button that points to a generic URL.
	A button with a link which navigates to a specific initialization form for a new work item to be created based on a given model you can select in the work item model attribute.
	A button which calls a REST endpoint to obtain dynamic navigation information. When pressed, the REST endpoint will be invoked and the response used to navigate to a specific work item view.
	A button which calls a REST endpoint and loads the resulting JSON object into the bound variable.
	A container that can only contain button widgets and has properties which affect the group of buttons contained.
	Used to show a horizontal line. The Horizontal line form widget is useful to structure large forms by splitting the form into sections, e.g. basic information, detail information, address, …
	A view to display content from a given source through an iframe.
	Used to preview documents as pdf. It can preview formats like doc or txt in addition to pdf.

Form widget

Description

Used to show static rich text.

The rich text can be formatted in various ways: regular, bold, italic, ordered list, unordered list, headings, and much more.

Used to render html code.

Used to show a list of options that are returned by a custom REST endpoint.

The dynamic list of options is build at runtime by calling a custom REST endpoint that the modeler has configured. The rest list form widget can be used to enable simple navigation inside your App. For this the modeler can configure the links that are followed when the user clicks one of the options in the list.

Used to show a list of work items that are returned by edoras one.

The dynamic list of work items is build at runtime by calling calling edoras one with a query that the modeler has configured. The rest list form widget can be used to enable simple navigation inside your App. For this the modeler can configure the links that are followed when the user clicks one of the options in the list.

Used to show an image.

Used to show a generic link.

A link which navigates to a specific initialization form for a new work item to be created based on a given model you can select in the work item model attribute

Used to show a link that navigates to a list of work items returned by a search using a specified query.

A link which renders a text including the numbers of elements returned by a count query you can specify.

The link text can be configured to show the number of elements returned by the query. Clicking the link navigates to the result of the query.

A link which renders a text including the numbers of elements returned by a REST endpoint.

The link text can be configured to show the number of elements returned by the REST query. Clicking the link navigates to the result of the REST query.

Used to show a button that points to a generic URL.

A button with a link which navigates to a specific initialization form for a new work item to be created based on a given model you can select in the work item model attribute.

A button which calls a REST endpoint to obtain dynamic navigation information. When pressed, the REST endpoint will be invoked and the response used to navigate to a specific work item view.

A button which calls a REST endpoint and loads the resulting JSON object into the bound variable.

A container that can only contain button widgets and has properties which affect the group of buttons contained.

Used to show a horizontal line.

The Horizontal line form widget is useful to structure large forms by splitting the form into sections, e.g. basic information, detail information, address, …

A view to display content from a given source through an iframe.

Used to preview documents as pdf. It can preview formats like doc or txt in addition to pdf.

the functionality of the REST list and the List form widgets is similar. The only difference is that the REST list form widget uses a custom REST endpoint to load the displayed items (which can be of any format) whereas the List form widget uses edoras one to load the displayed work items.

the functionality of the REST query link and the Query link form widget is similar. The only difference is that the REST query link form widget uses a custom REST endpoint to load the number of found elements whereas the Query link form widget uses edoras one to load the number of found elements.

the functionality of the Link and the Link button as well as the Query link and the Query link button is similar. The only difference is that the Link and the Query link form widgets are rendered as links whereas the Link button and the Query link button form widgets are rendered as buttons.

Output text area attributes

Attribute name	Description
Common	See Common attributes to learn more about the common attributes. The Output text area form widget does not support the Default value and the Editable attribute, as these do not make sense for read only widgets. The Value attribute of a Output text area form widget is rich text which supports the following formatting options (see toolbar buttons in the image below): bold, italic, and underline text style, font size, foreground and background color, left, center, and right text alignment, headline, sub-headline, and section headline style, ordered and unordered list, text indentation, horizontal line, links.

Attribute name

Description

Common

See Common attributes to learn more about the common attributes.

The Output text area form widget does not support the Default value and the Editable attribute, as these do not make sense for read only widgets.

The Value attribute of a Output text area form widget is rich text which supports the following formatting options (see toolbar buttons in the image below): bold, italic, and underline text style, font size, foreground and background color, left, center, and right text alignment, headline, sub-headline, and section headline style, ordered and unordered list, text indentation, horizontal line, links.

HTML attributes

Attribute name

Description

Common

See Common attributes to learn more about the common attributes.

The HTML widget does not support the value, default value and the editable attributes, as these do not make sense for read only widgets.

Content

Defines the content of the html.

The "Content" attribute of an HTML widget is a plain text for writing html code. It may include front-end expressions.

Border

Defines if it will show a wrapper border.

REST list attributes

Attribute name

Description

Common

See Common attributes to learn more about the common attributes.

The REST list form widget does not support the Value, the Default value and the Editable attribute, as these do not make sense for read only widgets.

Query URL

Used to load the items that are presented to the user from a URL.

The query URL attribute can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax.

The list form widget expects the items to be returned as list of JSON objects, e.g.

----
[ {
  "id" : "GEAR-a65c4a12-20b4-45d8-bb09-2105be7f0d1f",
  "title" : "edoras one Modeler",
  "value" : "GEAR-a65c4a12-20b4-45d8-bb09-2105be7f0d1f"
}, {
  "id" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac",
  "title" : "edoras one User",
  "value" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac"
} ]
----

List title

Used to define the title that is shown in the header of the list.

The list title attribute can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax.

Format

Used to compose a user friendly string from the JSON item.

The prefix to select an attribute from the JSON item is item. Literals have to be enclosed in quotes, attributes and literals can be concatenated with +.

So if the JSON item looks like

{
  "id" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac",
  "title" : "edoras one User",
  "value" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac"
}

then a format of Group: {{item.title}} results in Group: edoras one User being presented to the user for this JSON item.

Minimum number of visible items

Used to define the minimum height of the list.

The list height is forced to a height that can show at least a certain number of items. If the concrete list has less items then the missing space is filled with empty items. For example if there are 5 items to show and the minimum height is 10 then the list height is forced to a height that can show 10 items.

formComponentListRestRuntimeMinimumHeight

Maximum number of visible items

Used to define the maximum height of the list.

The list height is forced to a height that can show at most a certain number of items. If the concrete list has more items then the list shows a scroll with which the user can scroll in the list. For example if there are 15 items to show and the minimum height is 10 then the list height is forced to a height that can show 10 items.

Navigation URL

Used to define the URL to navigate to when the user clicks an item in the list.

The navigation URL attribute can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax.

The prefix to select an attribute from the JSON option is $item.

So if the JSON item looks like

{
  "id" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac",
  "title" : "edoras one User",
  "value" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac"
}

then a navigation URL of /GRP/{{$item.id}}/browse results in /GRP/GEAR-3456061f-4892-4ef4-b234-69217201cd09/browse being invoked when the user clicks the item in the list.

Target

Used to define the tab where the linked item is loaded.

Possible values are:

_blank ⇒ Load in a new tab
_self ⇒ Load in the same tab as it was clicked
tabname ⇒ Load in a named tab, if there is no tab with that name then a new tab is created with that name

List attributes

Attribute name

Description

Common

See Common attributes to learn more about the common attributes.

The List form widget does not support the Value, the Default value and the Editable attribute, as these do not make sense for read only widgets.

Query

The edoras one query that is used to load the work items for the list.

Typical queries:

type:CAS for:me: all cases that are assigned to me
type:TSK for:me,unassigned: all tasks that are either directly assigned to me or are unassigned
type:CAS app:foo: all cases that belong to the foo App

See section Searches in the User guide to learn more about the search syntax and about all possible search terms.

List title

Used to define the title that is shown in the header of the list.

The list title attribute can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax.

Format

Used to compose a user friendly string from the work item.

The prefix to select an variable from the work item item. Literals have to be enclosed in quotes, attributes and literals can be concatenated with +.

So if the format is Group: {{item.name}} then the work item is shown to the user as Group: edoras one User.

Minimum number of visible items

Used to define the minimum height of the list.

Maximum number of visible items

Used to define the maximum height of the list.

Navigation view

Used to set the target view for the link.

Possible values are:

Browse ⇒ The link points to the form view of the work item
Preview ⇒ The link points to the preview view of the work item

Target

Used to define the tab where the linked work item is loaded.

Possible values are:

_blank ⇒ Load in a new tab
_self ⇒ Load in the same tab as it was clicked
tabname ⇒ Load in a named tab, if there is no tab with that name then a new tab is created with that name

Image attributes

Attribute name

Description

Common

See Common attributes to learn more about the common attributes.

The Image form widget does not support the Value, Default value and the Editable attribute, as these do not make sense for read only widgets.

Source URL

Used to define the URL from which the image is loaded.

The source URL attribute can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax.

This can be an absolute URL like http://www.activiti.org/images/edorasware_logo.png or a relative URL that points to the content of a document work item, for example rest/workobjects/GEAR-faded1c0-a147-4fb1-9875-e13b185b0abe/content.

Maximum height

Used to define the maximum height of the image.

If set then the height of the Image form widget is forced to that height, which means the contained image is scaled down to that height. If not set then the height of the Image form widget is equals to the height of the contained image.

Refresh time (seconds)

Used to define a refresh internal in seconds.

The image is reloaded every x seconds, where x is the defined refresh time. This is useful if the Source URL attribute point to a dynamic image that can change over time.

Navigation URL

Used to define the URL to navigate to when the user clicks the image.

The navigation URL attribute can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax.

Target

Used to define the tab where image is loaded.

Possible values are:

_blank ⇒ Load in a new tab
_self ⇒ Load in the same tab as it was clicked
tabname ⇒ Load in a named tab, if there is no tab with that name then a new tab is created with that name

Link attributes

Attribute name

Description

Common

See Common attributes to learn more about the common attributes.

The Link form widget does not support the Value, Default value and the Editable attribute, as these do not make sense for read only widgets.

Link text

The attribute is used to define the link text.

Navigation URL

Used to define the URL to navigate to when the user clicks the link.

The navigation URL attribute can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax.

Context variables

Parameters that can be added to the URL linked. A dialog is opened where the name and the value of the parameters are specified. The value of the parameter can be a frontend-expression. See Frontend expressions to learn the frontend expression syntax.

An special parameter is "forwardTo", which defines the url where we will be redirected after executing the submit action of the page where we navigate to.

Tooltip

Used to define the tooltip, that is, a text which will appear when the mouse enters in the widget.

The tooltip attribute can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax.

Target

Used to define the tab where the linked item is loaded.

Possible values are:

_blank ⇒ Load in a new tab
_self ⇒ Load in the same tab as it was clicked
tabname ⇒ Load in a named tab, if there is no tab with that name then a new tab is created with that name

Create Link attributes

Attribute name

Description

Common

See Common attributes to learn more about the common attributes.

The Create Link form widget does not support the Value, Default value and the Editable attribute, as these do not make sense for read only widgets.

Link text

The attribute is used to define the link text.

Work item type

Type of the work item you want to create. The items can be Case, Task, Document or Process. The attribute can be set by a frontend-expression.See Frontend expressions to learn the frontend expression syntax.

Work item model

Select the models available to create, depending on the Work item type selected. The attribute can be set by a frontend-expression. See Frontend expressions to learn the frontend expression syntax.

Context variables

An special parameter is "forwardTo", which defines the url where we will be redirected after executing the submit action of the page where we navigate to.

Hide selectors

If its value is true, the template and parent selectors will be hidden. This only happens if the parameters (modelId and parentId) of the creation page where we are going to navigate are defined in the url.

Tooltip

Used to define the tooltip, that is, a text which will appear when the mouse enters in the widget.

The tooltip attribute can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax.

Target

Used to define the tab where the linked item is loaded.

Possible values are:

_blank ⇒ Load in a new tab
_self ⇒ Load in the same tab as it was clicked
tabname ⇒ Load in a named tab, if there is no tab with that name then a new tab is created with that name

Search Link attributes

Attribute name

Description

Common

See Common attributes to learn more about the common attributes.

The Search Link form widget does not support the Value, Default value and the Editable attribute, as these do not make sense for read only widgets.

Link text

The attribute is used to define the link text.

Query

The edoras one query that is used to load the work items for the list.

Typical queries:

type:CAS for:me: all cases that are assigned to me
type:TSK for:me,unassigned: all tasks that are either directly assigned to me or are unassigned
type:CAS app:foo: all cases that belong to the foo App

See section Searches in the User guide to learn more about the search syntax and about all possible search terms.

Show as button

If it’s wanted to show the link as a button

Tooltip

Used to define the tooltip, that is, a text which will appear when the mouse enters in the widget.

The tooltip attribute can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax.

Target

Used to define the tab where the linked item is loaded.

Possible values are:

_blank ⇒ Load in a new tab
_self ⇒ Load in the same tab as it was clicked
tabname ⇒ Load in a named tab, if there is no tab with that name then a new tab is created with that name

Search Count Link attributes

Attribute name

Description

Common

See Common attributes to learn more about the common attributes.

The Link form widget does not support the Value, Default value and the Editable attribute, as these do not make sense for read only widgets.

Link text

The attribute is used to define the link text.

The Link text attribute attribute can be expressed as a static value or as a frontend expression. See [frontend-expressions] to learn the frontend expression syntax. The value attribute supports the special $count frontend expression which represents the result count of the query. The value attribute as well supports different texts for singular and plural depending on the result counts. The syntax for this is [singular text|plural text].

So a value of $count case [|s] results in 1 case or 21 cases depending on the result count.

Query

The edoras one query that is used to load the work items for the list.

Typical queries:

type:CAS for:me: all cases that are assigned to me
type:TSK for:me,unassigned: all tasks that are either directly assigned to me or are unassigned
type:CAS app:foo: all cases that belong to the foo App

See section Searches in the User guide to learn more about the search syntax and about all possible search terms.

Tooltip

Used to define the tooltip, that is, a text which will appear when the mouse enters in the widget.

The tooltip attribute can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax.

Target

Used to define the tab where the linked item is loaded.

Possible values are:

_blank ⇒ Load in a new tab
_self ⇒ Load in the same tab as it was clicked
tabname ⇒ Load in a named tab, if there is no tab with that name then a new tab is created with that name

REST search count link attributes

Attribute name

Description

Common

See Common attributes to learn more about the common attributes.

The Link form widget does not support the Value, Default value and the Editable attribute, as these do not make sense for read only widgets.

Link text

The attribute is used to define the link text.

The Link text attribute attribute can be expressed as a static value or as a frontend expression. See [frontend-expressions] to learn the frontend expression syntax. The value attribute supports the special $count frontend expression which represents the result count of the REST query. The value attribute as well supports different texts for singular and plural depending on the result counts. The syntax for this is [singular text|plural text].

So a value of $count user [|s] results in 1 user or 21 users depending on the result count.

Count URL

Defines the REST URL that returns the count result (as a numerical value).

The count URL attribute can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax.

Navigation URL

Used to define the URL to navigate to when the user clicks the link.

The navigation URL attribute can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax.

Tooltip

Used to define the tooltip, that is, a text which will appear when the mouse enters in the widget.

The tooltip attribute can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax.

Target

Used to define the tab where the linked item is loaded.

Possible values are:

_blank ⇒ Load in a new tab
_self ⇒ Load in the same tab as it was clicked
tabname ⇒ Load in a named tab, if there is no tab with that name then a new tab is created with that name

Button attributes

Attribute name

Description

Common

See Common attributes to learn more about the common attributes.

The Button form widget does not support the Value, Default value and the Editable attribute, as these do not make sense for read only widgets.

Button text

The attribute is used to define the button text.

The Button text can be expressed as a static value or as a frontend expression. See [frontend-expressions] to learn the frontend expression syntax.

Navigation URL

Used to define the URL to navigate to when the user clicks the button.

The navigation URL attribute can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax.

Context variables

An special parameter is "forwardTo", which defines the url where we will be redirected after executing the submit action of the page where we navigate to.

Tooltip

Used to define the tooltip, that is, a text which will appear when the mouse enters in the widget.

The tooltip attribute can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax.

Target

Used to define the tab where the linked item is loaded.

Possible values are:

_blank ⇒ Load in a new tab
_self ⇒ Load in the same tab as it was clicked
tabname ⇒ Load in a named tab, if there is no tab with that name then a new tab is created with that name

Button alignment

The alignment of the button can be Left or Right.

Icon url

The url of an image, which will be displayed inside the button as an icon.

Icon alignment

The alignment of the icon inside the button. Can be Left or Right.

Create Button attributes

Attribute name

Description

Common

See Common attributes to learn more about the common attributes.

The Create button form widget does not support the Value, Default value and the Editable attribute, as these do not make sense for read only widgets.

Button text

The attribute is used to define the button text.

The Button text can be expressed as a static value or as a frontend expression. See [frontend-expressions] to learn the frontend expression syntax.

Work item type

Work item model

Context variables

An special parameter is "forwardTo", which defines the url where we will be redirected after executing the submit action of the page where we navigate to.

Hide selectors

Tooltip

Used to define the tooltip, that is, a text which will appear when the mouse enters in the widget.

The tooltip attribute can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax.

Target

Used to define the tab where the linked item is loaded.

Possible values are:

_blank ⇒ Load in a new tab
_self ⇒ Load in the same tab as it was clicked
tabname ⇒ Load in a named tab, if there is no tab with that name then a new tab is created with that name

Button alignment

The alignment of the button can be Left or Right.

Icon url

The url of an image, which will be displayed inside the button as an icon.

Icon alignment

The alignment of the icon inside the button. Can be Left or Right.

Inline Iframe attributes

Attribute

Description

Common

See Common attributes to learn more about the common attributes.

Source URL

The URL of the source to be displayed in the iframe, might also contain expressions.

Height

Used to define the maximum height of the iframe in pixels.

Show border

If is set to true, it renders a border around the iFrame.

Scrolling type

If is set to true, a scrolling bar is attached to the iframe or not. The possible values are:

Auto: the scrolling bar will appear just if the content of the iframe is taller than its height.
Yes: the scrolling bar will always appear.
No: the scrolling bar will never appear, so part of the iframe could be potentially hidden.

Pdf preview attributes

Attribute name

Description

Common

See Common attributes to learn more about the common attributes.

The Pdf preview form widget does not support the Default value and the Editable attribute, as these do not make sense for read only widgets.

Document source type

Possible values are:

id ⇒ The document source is the application, so the document is internal.
url ⇒ The document source is an external url.

Document source

It depends on the prevous attribute, the Document source type:

id ⇒ The id of the document, could be a frontend expression or the id document.
url ⇒ An external url should be provided.

Height

Defines the height of the pdf preview.

Show border

If is set to true, the pdf preview will have a wrapper border.

Button group attributes

Attribute name

Description

Common

See Common attributes to learn more about the common attributes.

The Button group form widget does not support the Default value and the Editable attribute, as these do not make sense for read only widgets.

Button alignment

The alignment of the button group. It can be Right, Left or Center.

Horizontal line attributes

Attribute name

Description

Common

See Common attributes to learn more about the common attributes.

The Label attribute is used to define the title that is displayed inside the horizontal line.

The Horizontal line form widget does not support the Default value and the Editable attribute, as these do not make sense for read only widgets.

3.5.7. Executable form widgets

The execution form widgets executes actions and saves the result in a variable.

Form widget

Description

A button which calls an endpoint and redirects to a workitem view depending on the result.

Button which executes a query and stores the result in a variable. In combination with a sub form, this allows to create search-like forms. If the button is clicked, the search is executed, the result stored in the variable and the subform will show the entries accordingly. If the query is using expression bound to search fields, you can create search forms this way.

A button which makes a call to an url and sets the result in the model, with timer interval capability.

A button which saves in a variable the result of a script.

A button which saves in a variable the result of a script and shows a text based on the result.

Dynamic Link Button attributes

Attribute name Description

Common

See Common attributes to learn more about the common attributes.

The Dynamic Link Button form widget does not support the Value, Default value and the Editable attribute, as these do not make sense for read only widgets.

Button text

The attribute is used to define the button text.

The Button text can be expressed as a static value or as a frontend expression. See [frontend-expressions] to learn the frontend expression syntax.

REST url

The REST url where the navigation information is retrieved. The response from the REST endpoint should have the following structure:

{
    "id" : "GEAR-35354f5d-1004-460a-8d53-88a04e0f22c1",
    "type" : "TSK",
    "view" : "browse"
}

Where id is a work object ID, type is the corresponding work object type and view is the name of the work object view that should be shown.

Target view

Define the view where will be redirected if the view is not defined in the REST url. If any is defined it will be redirected to Browse view by default.

Context variables

An special parameter is "forwardTo", which defines the url where we will be redirected after executing the submit action of the page where we navigate to.

Tooltip

Used to define the tooltip, that is, a text which will appear when the mouse enters in the widget.

The tooltip attribute can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax.

Target

Used to define the tab where the linked item is loaded.

Possible values are:

_blank ⇒ Load in a new tab
_self ⇒ Load in the same tab as it was clicked
tabname ⇒ Load in a named tab, if there is no tab with that name then a new tab is created with that name

Button alignment

The alignment of the button can be Left or Right.

Icon url

The url of an image, which will be displayed inside the button as an icon.

Icon alignment

The alignment of the icon inside the button. Can be Left or Right.

Search button attributes

Attribute name

Description

Common

See Common attributes to learn more about the common attributes.

The Search button form widget does not support the Value, Default value and the Editable attribute, as these do not make sense for read only widgets.

Button text

The attribute is used to define the button text.

The Button text can be expressed as a static value or as a frontend expression. See [frontend-expressions] to learn the frontend expression syntax.

Value

Is used to store the query result once executed (e.g. '{{searchResult}}'). You can bind the same variable to a subform for instance in order to render the result returned by the query.

Query

The edoras one query that is used to load the work items for the list.

Typical queries:

type:CAS for:me: all cases that are assigned to me
type:TSK for:me,unassigned: all tasks that are either directly assigned to me or are unassigned
type:CAS app:foo: all cases that belong to the foo App

See section Searches in the User guide to learn more about the search syntax and about all possible search terms.

Max result size

The maximum number of items being returned by the query in order to limit the result, might even be an expression. See Frontend expressions to learn the frontend expression syntax.

Auto execute

Automatically executes the query during initialization of the form, if set to 'true', might even be an expression. See Frontend expressions to learn the frontend expression syntax.

Tooltip

Used to define the tooltip, that is, a text which will appear when the mouse enters in the widget.

The tooltip attribute can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax.

Target

Used to define the tab where the linked item is loaded.

Possible values are:

_blank ⇒ Load in a new tab
_self ⇒ Load in the same tab as it was clicked
tabname ⇒ Load in a named tab, if there is no tab with that name then a new tab is created with that name

Button alignment

The alignment of the button can be Left or Right.

Icon url

The url of an image, which will be displayed inside the button as an icon.

Icon alignment

The alignment of the icon inside the button. Can be Left or Right.

REST button attributes

Attribute name

Description

Common

See Common attributes to learn more about the common attributes.

The REST button form widget does not support the Default value and the Editable attribute, as these do not make sense for read only widgets.

Button text

The attribute is used to define the button text.

The Button text can be expressed as a static value or as a frontend expression. See [frontend-expressions] to learn the frontend expression syntax.

Value

Is used to store the REST endpoint result once executed (e.g. '{{result}}'). You can bind the same variable to a subform for instance in order to render the result returned by the REST endpoint.

REST url

Define the URL of the REST endpoint which returns the data.

Refresh time

The milliseconds interval to execute the button automatically in every tick. If it’s not defined it will not be executed automatically.

Auto execute

Automatically executes the rest request during initialization of the form, if set to 'true', might even be an expression. See Frontend expressions to learn the frontend expression syntax.

Tooltip

Used to define the tooltip, that is, a text which will appear when the mouse enters in the widget.

The tooltip attribute can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax.

Target

Used to define the tab where the linked item is loaded.

Possible values are:

_blank ⇒ Load in a new tab
_self ⇒ Load in the same tab as it was clicked
tabname ⇒ Load in a named tab, if there is no tab with that name then a new tab is created with that name

Button alignment

The alignment of the button can be Left or Right.

Icon url

The url of an image, which will be displayed inside the button as an icon.

Icon alignment

The alignment of the icon inside the button. Can be Left or Right.

Script button attributes

Attribute name

Description

Common

See Common attributes to learn more about the common attributes.

The Script button form widget does not support the Default value and the Editable attribute, as these do not make sense for read only widgets.

Button text

The attribute is used to define the button text.

The Button text can be expressed as a static value or as a frontend expression. See [frontend-expressions] to learn the frontend expression syntax.

Value

Is used to store the returned value of the script once executed (e.g. '{{scriptResult}}'). e.g It’s possible to bind the variable to a text widget in order to render the result returned by the script.

Script

The script which will be executed.

Inside the script scope is possible to access to a variable called elementId which have the value of the id attribute of the script button.

Is possible to use some util methods or properties:

returnAsyncValue (Function): you can execute this function a save the value asynchronously. For example when in the script we do an AJAX call.
elementId (String): the attribute id of the clicked button.
element (Object): the button clicked.

Refresh time

The milliseconds interval to execute the button automatically in every tick. When is empty, it will not be executed automatically.

Auto execute

If it is set to 'true', the script is executed automatically during initialization of the form. It might even be an expression. See Frontend expressions to learn the frontend expression syntax.

Tooltip

Used to define the tooltip, that is, a text which will appear when the mouse enters in the widget.

The tooltip attribute can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax.

Button alignment

The alignment of the button can be Left or Right.

Icon url

The url of an image, which will be displayed inside the button as an icon.

Icon alignment

The alignment of the icon inside the button. Can be Left or Right.

Selection script button attributes

Attribute name

Description

Common

See Common attributes to learn more about the common attributes.

The Selection Script button form widget does not support the Default value and the Editable attribute, as these do not make sense for read only widgets.

Button text

The attribute is used to define the button text.

The Button text can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax.

Value

Is used to store the returned value of the script once executed (e.g. '{{scriptResult}}').

Script

The script which will be executed.

Inside the script scope is possible to access to a variable called elementId which have the value of the id attribute of the script button.

Is possible to use some util methods or properties:

returnAsyncValue (Function): you can execute this function a save the value asynchronously. For example when in the script we do an AJAX call.
elementId (String): the attribute id of the clicked button.
element (Object): the button clicked.

Refresh time

The milliseconds interval to execute the button automatically in every tick. When is empty, it will not be executed automatically.

Auto execute

If it is set to 'true', the script is executed automatically during initialization of the form. It might even be an expression. See Frontend expressions to learn the frontend expression syntax.

Result format

Shows the result of the script in a text field. If the result is an object saved in the 'result variable', it is possible to display its properties by setting it to {{scriptResult .anyProperty}}

Tooltip

Used to define the tooltip, that is, a text which will appear when the mouse enters in the widget.

The tooltip attribute can be expressed as a static value or as a frontend expression. See Frontend expressions to learn the frontend expression syntax.

3.5.8. Nesting form widgets

The nesting form widgets allow to nest widgets.

The data model of a nested form is usually stored in a nested data context. If configured that way the forms and the data model nest in a corresponding way: A field in a nested form then becomes a attribute in the nested data context.

Nested forms can be repeated. This way it is possible to define lists in the data model.

Usually nested forms are rendered in a way that the user can clearly see that the form fields belong to a nested form. But if desired nested forms can be rendered in a transparent way. The user can then not tell if a field comes from the main form or from a nested form.

Form widget

Description

Used to nest forms of a single type.

Used to nest forms of multiple types.

Single-type subform attributes

Attribute

Description

Form reference

Used to define the form that is rendered in place of the subform.

The editor for this attribute allows to pick an existing form or to create a new one.

Element name

Used to define the text for the add button.

Common

See Common attributes to learn more about the common attributes.

The Value attribute is used to define the nested data context. This means if the Value is set to foo then all data inside the subform is stored in the foo attribute of the data model.

This widget does not support the Label position, the Default value, and the Description attribute, as these do not make sense for nesting widgets.

Validation

This widget supports the minimum number of children and the maximum number of children validation.

See Validation attributes to learn more about validation.

Multiple elements

Used to define if the user can repeat the form or not.

If true, additional buttons are rendered to let the user add new forms and remove existing ones.

formComponentSingleTypeSubformRuntimeRepeating

Show border

Used to define if the form inside the subform form widget is rendered nested or not.

If true the form is rendered in a nested way and the user can clearly see that this is a nested form. If false the form is rendered in a transparent way and the user cannot distinguish if a field comes form the main form or from the nested form.

formComponentSingleTypeSubformRuntimeTransparent

Show add/remove buttons

If the subform can hold multiple elements, this attribute specifies whether the add/remove buttons should be shown and thus allowing the user to create new elements or to remove existing elements. This can also be done using a dynamic expression.

Collapsible

If true, the subform can be collapsed/expanded by clicking on an arrow ▲/▼.

Collapsed

If true, the subform will appear collapsed by default.

It supports FE expression by writing it in "Collapsed(RT)" field. Using FE expression, if the value of the expression changes, it will be applied to the subform, that is, if it becomes true, the subform will be collapsed and vice versa.

Multi-type subform attributes

Attribute

Description

Form references

Used to define the forms that are rendered in place of the subform.

The editor to define the form references asks for a discriminator value, the form reference and display name. The discriminator value identifies the form reference and hence the form to be used inside the data model. The display name is used to define the text for the add button.

The value stored in the discriminator attribute decides which form is used to display the data in the sub data context.

Common

See Common attributes to learn more about the common attributes.

The Value attribute is used to define the nested data context. This means if the Value is set to foo then all data inside the subform is stored in the foo attribute of the data model.

This widget does not support the Label position, the Default value, and the Description attribute, as these do not make sense for nesting widgets.

Validation

This widget supports the minimum number of children and the maximum number of children validation.

See Validation attributes to learn more about validation.

Multiple elements

Used to define if the user can repeat the form or not.

If true, additional buttons are rendered to let the user add new forms and remove existing ones.

Show border

Used to define if the form inside the subform form widget is rendered nested or not.

Show add/remove buttons

Collapsible

If true, the subform can be collapsed/expanded by clicking on an arrow ▲/▼.

Collapsed

If true, the subform will appear collapsed by default.

The attachment form widget allows to attach files.

Attribute

Description

Common

See Common attributes to learn more about the common attributes.

Validation

The attachment form widget supports the minimum files and the maximum files validation.

See Validation attributes to learn more about validation.

Preview type

Used to define the preview type.

The following values are allowed:

None: display no preview
Icon: display an icon that identifies the file type as preview
Thumbnail: display a thumbnail of the attached file as preview, the thumbnail is generated in the backend

Thumbnail maximum height

Used to define the maximum height of the thumbnail.

This attribute is only available when the preview type is Thumbnail.

Select file message

Used to define the message that is shown to the user inside the attachment form widget.

By default the attachment form widget shows Please select file to the user.

3.6. Process Palette

This section describes the elements available in the process modelling palette of edoras one. Each modeling element and it’s corresponding attributes are described in detail below. Since edoras one is based on BPMN 2.0 huge parts of the modelling capabilities come from there. Currently, edoras one does not support the full BPMN 2.0 standard for execution. The process palette contains only the BPMN2.0 elements that are currently supported by the engine. Besides the BPMN 2.0 standard elements, edoras one provides some dedicated process activities that can be used within the processes. These edoras one specific activities are dedicated implementations of BPMN 2.0s generic service task. They are implemented using the custom extensions hook of BPMN 2.0 so if you import a process model to another system that supports BPMN 2.0 these activities are considered as generic service tasks.

There are several attributes, that are available for all modelling elements:

Table 17. Common attributes
Attribute Name	Description
Name	The name of the element, displayed on the diagram. This attribute is not equal to the id of the element.
Documentation	Use this attribute to add any documentation / description to the element. The content of the element can not be displayed on the model graphics, but is exported to the BPMN 2.0 XML.
Custom Properties	Define arbitrary properties as key value pairs. The attribute is exported to the BPMN 2.0 XML and can be accessed at runtime.
Background Colour	Specify the background colour of the element in the diagram.
Border Colour	Specify the border colour of the element in the diagram.
LoopType	Selection of the loop type. See Multi Instance to know more about loops.

There are several attributes, that are available to customize the font format of all modelling elements in the diagram. If the attributes are set at process level, all the components of the process will contain these attributes by default:

Table 18. Text format attributes
Attribute Name	Description
Font size	Specify the font size of the element in the diagram.
Font weight	Specify the font weight of the element in the diagram.
Font style	Specify the font style of the element in the diagram.
Font Color	Specify the font color of the element in the diagram.

These attributes can also be modified by the shortcut with a "T" icon placed in the left-bottom corner of the components. Clicking on this brings up a text format dialog where the formatting can be changed as required. The dialog includes a button to remove the style format and goes back to the default format.

Moreover the process can contain attributes associated to the whole process. In order to set them click in the design area without selecting any element.

Table 19. Process attributes
Attribute Name	Description
Init form ref	The reference to a form which will be rendered before the process starts by the 'Start process' action.
Label expression	Specify a label expression for tasks within this process if you want something else being used as the name property.
Custom Properties	Define arbitrary properties as key value pairs. The cutom properties will be saved to a process level.
Is executable	If is set to false the deployment will ignore the process. Once is set to true and the process deployed
Text format attributes	See the table above. If the text format attributes are set at process level, all the components of the process will be created with the format set.

3.6.1. Events

Start Event

A none start event technically means that the trigger for starting the process instance is unspecified. This means that the engine cannot anticipate when the process instance must be started.

Figure 8. Graphical Representation

Table 20. Specific attributes
Attribute Name	Attribute Type
Description	none

Any sub-process has always to start with a none start event.

Message start event

A message start event can be used to start a process instance using a named message. This effectively allows us to select the right start event from a set of alternative start events using the message name.

When deploying a process definition with one or more message start events, the following considerations apply:

The name of the message start event must be unique across a given process definition. A process definition must not have multiple message start events with the same name. edoras one throws an exception upon deployment of a process definition such that two or more message start events reference the same message of if two or more message start events reference messages with the same message name.
The name of the message start event must be unique across all deployed process definitions. edoras one throws an exception upon deployment of a process definition such that one or more message start events reference a message with the same name as a message start event already deployed by a different process definition.
Process versioning: Upon deployment of a new version of a process definition, the message subscriptions of the previous version are cancelled. This is also true for message events that are not present in the new version.

Figure 9. Graphical Representation

Table 21. Specific attributes
Attribute Name	Description
Is interrupting	This attribute denotes whether the sub-process encompassing the event sub-process should be cancelled or not.
Message name
Operation name

Error start event

An error start event can be used to trigger an Event Sub-Process. An error start event cannot be used for starting a process instance.

An error start event is always interrupting.

Figure 10. Graphical Representation

Table 22. Specific attributes
Attribute Name	Description
Error code	The error code associated to the event.

Timer start event

A timer start event is used to create process instance at given time. It can be used both for processes which should start only once and for processes that should start in specific time intervals. Timer start event is scheduled as soon as process is deployed. That means that the process will be started without parent case. When is needed a timer after start a process (not deploy) then should be used an intermediate timer event after a start event.

A process cannot be deployed if after timer start event there is a create case, create case from subform, create pdf or convert to PDF component.

A subprocess cannot have a timer start event.

There is no need to start an instance explicitly, although starting a process is not restricted and will cause one more starting of the process at the time invocation.

When a new version of a process with a start timer event is deployed, the job corresponding with the previous timer will be removed. The reasoning is that normally it is not wanted to keep automatically starting new process instances of this old version of the process.

Figure 11. Graphical Representation

Table 23. Specific attributes
Attribute Name	Description
Is interrupting	This attribute denotes whether the sub-process encompassing the event sub-process should be cancelled or not.
Timer properties	Opens a dialog to specify when the timer should fire.

Intermediate Event

An intermediate event marks the occurrence of a particular business event.

Process execution is not delayed.

Figure 12. Graphical Representation

Table 24. Specific attributes
Attribute Name	Description
Execution listeners	The execution listeners to be executed when the process token arrives in the event.

Message catching intermediate event

Message Catching Intermediate Events are used to model wait state for particular message event with a specified name. After message catching process instance continues in its execution.

Message Catching Intermediate Event style rules: * By convention, message catching intermediate events are named after the event they are waiting for. (e.g. "Additional data received")

Figure 13. Graphical Representation

Table 25. Specific attributes
Attribute Name	Description
Message name	The name of the message that the event is waiting for
Operation name

Timer intermediate event

Timer Intermediate Events are used to model wait state driven by a time.

Timer Intermediate Event style rules: * By convention, timer intermediate events are named after the event they are waiting for. (e.g. "Delivery deadline reached")

Figure 14. Graphical Representation

Table 26. Specific attributes
Attribute Name	Description
Timer properties	A wizard to configure the timer.

Signal catching intermediate event

Signal Catching Intermediate Events are used to model wait for particular signal. After catching the signal the process execution continues. The signal is not consumed after the catching. One signal can fire execution of several independent process instances in one step.

Signal Catching Intermediate Event style rules: * By convention, signal catching intermediate events are named after the event they are waiting for. (e.g. "New customer arrived")

Figure 15. Graphical Representation

Table 27. Specific attributes
Attribute Name	Description
Is interrupting	If the event is used as a boundary event. Specify if the related activity should be terminated when the signal arrives.
Signal name	The name of the signal the event is waiting for.

Signal throwing intermediate event

Signal Throwing Intermediate Events are used to model sending a particular signal. After sending the signal the process execution continues. One signal can fire execution of several independent process instances in one step.

Signal Throwing Intermediate Event style rules: * By convention, signal throwing intermediate events are named after the event they are throwing.

Figure 16. Graphical Representation

Table 28. Specific attributes
Attribute Name	Description
Execution listeners	The execution listeners to be executed when the process token arrives in the event.
Signal name	The name of the signal the event is throwing.

Boundary error event

An intermediate catching error on the boundary of an activity, or boundary error event for short, catches errors that are thrown within the scope of the activity on which it is defined.

Defining a boundary error event makes most sense on an embedded subprocess, or a call activity, as a subprocess creates a scope for all activities inside the subprocess. Errors are thrown by error end events. Such an error will propagate its parent scopes upwards until a scope is found on which a boundary error event is defined that matches the error event definition.

When an error event is caught, the activity on which the boundary event is defined is destroyed, also destroying all current executions within (e.g. concurrent activities, nested subprocesses, etc.). Process execution continues following the outgoing sequence flow of the boundary event.

Figure 17. Graphical Representation

Table 29. Specific attributes
Attribute Name	Description
Error code	The error code associated to the event.

The errorCode is used to match the errors that are caught:

If errorRef is omitted, the boundary error event will catch any error event, regardless of the errorCode of the error. In case an errorRef is provided and it references an existing error, the boundary event will only catch errors with the same error code. In case an errorRef is provided, but no error is defined in the BPMN 2.0 file, then the errorRef is used as errorCode (similar for with error end events).

End event

A none end event means that the result thrown when the event is reached is unspecified. As such, the engine will not do anything extra besides ending the current path of execution.

Figure 18. Graphical Representation

Table 30. Specific attributes
Attribute Name	Description
none

Error end event

When process execution arrives in an error end event, the current path of execution is ended and an error is thrown. This error can caught by a matching intermediate boundary error event. In case no matching boundary error event is found, an exception will be thrown.

Figure 19. Graphical Representation

Table 31. Specific attributes
Attribute Name	Description
Error code	The error code associated to the event.

Terminate end event

A terminate end event means that all active tasks for the given process are terminated. edoras one extension may archive parent case also.

Figure 20. Graphical Representation

Table 32. Specific attributes
Attribute Name	Description
Archive type	The options to archive the parent case which contains the given process. * Do not archive * Archive only if there are no active children * Archive only if there are only active documents * Archive the case and all children

Figure 21. Terminate end event limitation

Terminate end event should reference persisted process instances. Note that a process instance without wait state is not persisted. However wait state can be easily created by changing automatic component property from synchronous to asynchronous.

3.6.2. Tasks

User Task

A user task is used to model work that needs to be done by a human actor. When the process execution arrives at such a user task, a new task is created in the task list of the user(s) or group(s) assigned to that task.

Figure 22. Graphical Representation

Table 33. Specific attributes
Attribute Name	Description
Guid	The task guid. It can not be edited.
Form Reference	Select a form to be attached to the current task. You can also directly create a new form from here
Owner	Set the owner of the task by selecting an existing user statically
Owner (RT)	Use a backend expression to evaluate the owner dynamically at runtime
Assignee	Set the assignee of the task by selecting an existing user statically
Assignee (RT)	Use a backend expression to evaluate the assignee dynamically at runtime
Candidate Users	Set the candidate users of the task by selecting existing users statically
Candidate Users (RT)	Use a backend expression to evaluate the candidate users dynamically at runtime
Candidate Groups	Set the candidate users of the task by selecting existing groups statically
Candidate Groups (RT)	Use a backend expression to evaluate the candidate groups dynamically at runtime
Priority	Set the priority of the task by using a literal or a backend expression. The priority is not currently not supported at runtime
Due Date	Set the due date of the task. The due date is currently not supported at runtime
Allowed actions	The allowed actions of the task can be edited. If they are removed, will not appear in one. The Assign, Share and Create Variables can be selected or removed.
Mail Attributes	Refer to Send Mail Service Task for the usage of these attributes. By using this attribute section, you cause the engine to additionally send an email when the task is created

Manual task

A Manual task defines a task that is external to the BPM engine. It is used to model work that is done by somebody, which the engine does not need to know of, nor is there a system or UI interface. For the engine, a manual task is handled as a pass-through activity, automatically continuing the process from the moment process execution arrives into it.

Figure 23. Graphical Representation

Table 34. Specific attributes
Attribute Name	Description
none

Service Task

A service task is a task that uses some sort of service, which could be a web service or an automated application.

There are 4 ways of declaring how to invoke Java logic:

Specifying a class that implements JavaDelegate or ActivityBehavior.
Evaluating an expression that resolves to a delegation object.
Invoking a method expression.
Evaluating a value expression.

The named objects are resolved in the execution’s process variables and (if applicable) in the Spring context.

Please note that only one of the following attributes must be filled: class, expression or delegateExpression.

Figure 24. Graphical Representation

Table 35. Specific attributes
Attribute Name	Description
Expression	Specify a UEL method expression or UEL value expression that should be evaluated. Example UEL method: #{printer.printMessage()}, method printMessage (without parameters) will be called on the named object called printer. It’s also possible to pass parameters with a method used in the expression like #{printer.printMessage(execution, myVar)} Example UEL value expression: #{split.ready} , the getter method of property ready, getReady (without parameters), will be called on the named bean called split.
Delegate expression	Expression that resolves to a delegation object. It is also possible to use an expression that resolves to an object provided in the attribute. This object must follow the same rules as objects that are created when the class attribute is used. Example: ${delegateExpressionBean}, the delegateExpressionBean is a bean that implements the JavaDelegate interface, defined in for example the Spring container.
Result variable	The return value of a service execution (for service task using expression only) can be assigned to an already existing or to a new process variable by specifying the process variable name as a literal value for resultVariable attribute of a service task definition. Any existing value for a specific process variable will be overwritten by the result value of the service execution. When not specifying a result variable name, the service execution result value gets ignored.
Class	Class that implements JavaDelegate or ActivityBehaviorSpecify. The class is called during process execution. The fully qualified classname needs to be provided by the attribute. Example: org.activiti.MyJavaDelegate
Owner	Set the owner of the task by selecting an existing user statically
Owner (RT)	Use a backend expression to evaluate the owner dynamically at runtime
Assignee	Set the assignee of the task by selecting an existing user statically
Assignee (RT)	Use a backend expression to evaluate the assignee dynamically at runtime
Candidate Users	Set the candidate users of the task by selecting existing users statically
Candidate Users (RT)	Use a backend expression to evaluate the candidate users dynamically at runtime
Candidate Groups	Set the candidate users of the task by selecting existing groups statically
Candidate Groups (RT)	Use a backend expression to evaluate the candidate groups dynamically at runtime

Create Case Service Task

The Create Case Service Task can be used to create a new case from within a process. Input data for the new case can be mapped and the newly created case can be referenced form the current case if needed.

Figure 25. Graphical Representation

Table 36. Specific attributes
Attribute Name	Description
Case Model	Select a case model for the new case to be created
Init Variables	Specify additional variables that should be initialized during the creation of the new case
Case Name	Set the name of the new case using literals or backend expressions
CaseId Variable	specify a variable name where the id of the newly created case should be stored in the current case. This is optional
ParentId	specify an expression to resolve the work item id to be the parent item of the new case to be created. This is optional

Create case from subform service task

The create case from subform service Task is an itemization of the create case service task. Here you can specify a variable (subform) of the current workitem hierarchy as the input values for the new case instead of binding all input parameters manually.

Figure 26. Graphical Representation

Table 37. Specific attributes
Attribute Name	Description
Case Model	Select a case model for the new case to be created
Init Variables	Specify additional variables that should be initialized during the creation of the new case
Case Name	Set the name of the new case using literals or backend expressions
CaseId Variable	specify a variable name where the id of the newly created case should be stored in the current case. This is optional
ParentId	specify an expression to resolve the work item id to be the parent item of the new case to be created. This is optional
Subform Variable	Specify the variable name where the subform to create the new case from is bound to
Remove Subform Variable	If set to true, the variable of the subform will be removed from the data model after creating the case

Create document service task

edoras one allows to enhance business processes with document creation service tasks. The create document service task creates a copy of the specified document template insid the current case. In case the document template is either a MS Word or Adobe PDF form, form fields will automatically be populated with execution data. Refer to Document Placeholders for more information.

Figure 27. Graphical Representation

Table 38. Specific attributes
Attribute Name	Description
Document Model	Select a document model for the new document to be created
Document Id variable name	Specify a variable name where the id of the newly created document should be stored in the current case. This is optional.
Document name	The name of the document to be created within the case, might also contain expressions

Convert to pdf service task

edoras one allows to enhance business processes with document conversion to pdf service tasks. The 'Convert to pdf' service converts a specified document to pdf format.

Figure 28. Graphical Representation

Table 39. Specific attributes
Attribute Name	Description
Document Id	Specify the id if the document which will be converted to pdf.
Save as copy	Indicates if the pdf document is saved as a new document.
Document id variable	Only active when 'Save as copy' is true. Specify a variable name where the id of the newly created document should be stored in the current case.

Send Mail Service Task

edoras one allows to enhance business processes with automatic mail service tasks that send e-mails to one or more recipients, including support for cc, bcc, mail templates, … etc.

See section Mail Server in the Operators Guide for information on configuring the mail server in an on-premise environment

Figure 29. Graphical Representation

Table 40. Specific attributes
Attribute Name	Description
Mail Model	This is a reference to a mail model in the current App. This model defines rich-text templates for the mail subject and body. Backend expressions in the mail model templates will be replaced when the mail is sent
Mail Recipient	The mail recipient is a required expression or literal that defines the email recipient (or multiple recipients)
Mail Reply-To	The mail reply-to is an optional expression that specify an explicit reply address. If no reply address is defined then the global system default will be used (which will vary from installation to installation)
Mail CC	Specify one or multiple CC recipients using literals or backend expressions. This attribute is optional
Mail Bcc	Specify one or multiple BCC recipients using literals or backend expressions. This attribute is optional
Mail Priority	An optional expression or literal that specifies the mail priority (usually an integer in the range 1 - 5)
Mail Headers	Specify additional mail headers. They will be applied before the message is sent
Attachments ids	The list of documents sent by the email. The documents can be referenced by its id or a backend expression.

Invoke REST endpoint service task

The Invoke REST endpoint service task provides a generic client to call arbitrary REST endpoints. The task supports all HTTP operations, Basic Authentication, custom headers and different mime-types.

Figure 30. Graphical Representation

Table 41. Specific attributes
Attribute Name	Description
Protocol	Specify the protocol to use for the request. HTTP and HTTPS are supported
Request Type	Specify the type of the HTTP Request. GET, POST, PUT and DELETE are supported
Request Headers	Add additional HTTP message headers to your request
Request Body	Specify the message body that will be sent with the request. You can use backend expressions to include data from the data model within your message body structure. This can only be used with POST and PUT requests
Content Type	Define the content type header to be set within the request. This value will be overwritten if you have set a content type in the Header attribute
Host Name	The host name of the remote server (e.g. service.edorasware.com
Port Number	The port number of the remote server. If not specified, 80 is used
Request Path	Specify the path to the endpoint on the remote server. The path must start with a leading / You can use backend expressions to set the path dynamically at runtime based on values from the data model
Request Parameters	Specify the parameters that are passed as part of the request URL. Multiple parameters can be defined using the editor provided
Username	If the remote server requires basic authentication specify the username of the user you want to use for the request
Password	If the remote server requires basic authentication specify the password of the user you want to use for the request
Response Type	Select the format of the response of the REST call. Currently JSON and XML are supported
Set Variables	Map the response data to your data model. specify the variable name and use X-Path expressions to select the respecting value from the response
Overwrite if existing	Set to true if you want to overwrite the values of existing variables with the values from the REST calls response

JSON to XML mapping

The JSON to XML mapping used to prepare data for the XPath expression evaluation is mainly intuitive, but for completeness here is a quick summary of how different JSON content is mapped:

Table 42. JSON to XML mapping
JSON	XML	XPath example	Result
`{ 'node': 'value' }`	`<root> <node original-type="string">value</node> </root>`	//node	value
`{ 'node': [ 'value1', 'value2' ] }`	`<root> <node1 original-type="string">value1</node1> <node2 original-type="string">value2</node2> </root>`	//node[2]	value2
`{ 'node': { 'child':'cValue' } }`	`<root> <node> <child original-type="string">cValue</child> </node> </root>`	//child	cValue
`'single value'`	`<root original-type="string">single value</root>`	/root	single value
`[ 'one', 'two', 'three' ]`	`<json> <root original-type="string">one</root> <root original-type="string">two</root> <root original-type="string">three</root> </json>`	/json/root[2]	two

Note that in the case where multiple values are in the top-level JSON content, an additional root node (json) will be created as XML may only have a single root node.

Initialize variables service task

Use the initialize variables service task to initialize arbitrary variables in the current workitem hierarchy. You can use Expressions or literals to set the values of the variables.

Figure 31. Graphical Representation

Table 43. Specific attributes
Attribute Name	Description
Init Variables	Specify variable name and target workitem of the variable you want to initialize using literals. Use literals or backend expressions to specify the value of the variable
Overwrite if existing	If set to true, the values of already defined variables will be overwritten. Otherwise, already initialized variables are skipped

Initialize variables on query result

Use the 'Initialize variables on query result' service task to initialize variables in every work item being returned by a query. You can use Expressions or literals to set the values of the variables.

Figure 32. Graphical Representation

Table 44. Specific attributes
Attribute Name	Description
Query	The specified variables will be applied to every work item being returned by that query.
Variables to initialize	Specify variable name and target workitem of the variable you want to initialize using literals. Use literals or backend expressions to specify the value of the variable. For each variable it’s specified the flag 'Overwrite if existing', If set to true, the value of variable will be overwritten. Otherwise, already initialized variable is skipped
Result list item name	The name of the local variable representing the currently processed result list work item. This name might be used in an expression to access the current work item (e.g. '#{item.name}')
Result list item index	The name of the local variable representing the index (0-based) of the currently processed result list work item. This might be used in an expression to access the loop counter (index) of the currently processed work item (e.g. '#{itemIndex+1}')

Comment service task

Use the comment service task to add a comment to an arbitrary workitem reachable by the expression resolver. You can use templates similar to the ones in the send mail service Task to add formatted, structured comments.

Figure 33. Graphical Representation

Table 45. Specific attributes
Attribute Name	Description
Comment Target Object	Use an expression that resolves to the workitem where the comment should be added to the comment-stream
History variable name	Stores the last comment added in the given variable name. If empty the comment is added to the comment-stream.
Comment User	Specify a the user in whose name the comment is created using an expression
Comment Template	Select the template for the comment

3.6.3. Execution elements

Sequence Flow

A sequence flow is the connector between two elements of a process. After an element is visited during process execution, all outgoing sequence flow will be followed. This means that the default nature of BPMN 2.0 is to be parallel: two outgoing sequence flow will create two separate, parallel paths of execution.

A sequence flow can have a condition defined on it. When a BPMN 2.0 activity is left, the default behavior is to evaluate the conditions on the outgoing sequence flow. When a condition evaluates to true, that outgoing sequence flow is selected. When multiple sequence flow are selected that way, multiple executions will be generated and the process will be continued in a parallel way.

The above holds for BPMN 2.0 activities (and events), but not for gateways. Gateways will handle sequence flow with conditions in specific ways, depending on the gateway type.

Currently conditionalExpressions can only be used with Backend Expressions, detailed info about these can be found in section Backend Expressions. The expression used should resolve to a boolean value, otherwise an exception is thrown while evaluating the condition.

All BPMN 2.0 tasks and gateways can have a default sequence flow. This sequence flow is only selected as the outgoing sequence flow for that activity if and only if none of the other sequence flow could be selected. Conditions on a default sequence flow are always ignored.

Figure 34. Graphical Representation

Table 46. Specific attributes
Attribute Name	Description
Condition Type	Specify the condition type of the message flow. standard an conditional flow behave the same, but are displayed differently. Use a backend expression in the Condidtion Expression Attribute to specify the condition. If you set the condition type to Default, this flow is executed when no other flow condition evaluates to true
Condition Expression	A backend expression that must evaluate to a boolean value

Exclusive Gateway

An exclusive gateway (also called the XOR gateway or more technical the exclusive data-based gateway), is used to model a decision in the process. When the execution arrives at this gateway, all outgoing sequence flow are evaluated in the order in which they are defined. The sequence flow which condition evaluates to true (or which doesn’t have a condition set, conceptually having a 'true' defined on the sequence flow) is selected for continuing the process.

Note that the semantics of outgoing sequence flow is different to that of the general case in BPMN 2.0. While in general all sequence flow which condition evaluates to true are selected to continue in a parallel way, only one sequence flow is selected when using the exclusive gateway. In case multiple sequence flow have a condition that evaluates to true, the first one defined in the XML (and only that one!) is selected for continuing the process. If no sequence flow can be selected, an exception will be thrown.

Figure 35. Graphical Representation

Table 47. Specific attributes
Attribute Name	Description
none

Inclusive gateway

The inclusive gateway can be seen as a combination of an exclusive and a parallel gateway. Like an exclusive gateway you can define conditions on outgoing sequence flows and the inclusive gateway will evaluate them. But the main difference is that the inclusive gateway can take more than one sequence flow, like the parallel gateway. The functionality of the inclusive gateway is based on the incoming and outgoing sequence flow:

fork: all outgoing sequence flow conditions are evaluated and for the sequence flow conditions that evaluate to true the flows are followed in parallel, creating one concurrent execution for each sequence flow.
join: all concurrent executions arriving at the inclusive gateway wait in the gateway until an execution has arrived for each of the incoming sequence flows that have a process token. This is an important difference with the parallel gateway. So in other words, the inclusive gateway will only wait for the incoming sequence flows that will be executed. After the join, the process continues past the joining inclusive gateway.

Note that an inclusive gateway can have both fork and join behavior, if there are multiple incoming and outgoing sequence flow for the same inclusive gateway. In that case, the gateway will first join all incoming sequence flows that have a process token, before splitting into multiple concurrent paths of executions for the outgoing sequence flows that have a condition that evaluates to true.

Note that at least one condition must be true

Figure 36. Graphical Representation

Table 48. Specific attributes
Attribute Name	Description
none

Parallel gateway

Gateways can also be used to model concurrency in a process. The most straightforward gateway to introduce concurrency in a process model, is the Parallel Gateway, which allows to fork into multiple paths of execution or join multiple incoming paths of execution. The functionality of the parallel gateway is based on the incoming and outgoing sequence flow:

fork: all outgoing sequence flow are followed in parallel, creating one concurrent execution for each sequence flow.
join: all concurrent executions arriving at the parallel gateway wait in the gateway until an execution has arrived for each of the incoming sequence flow. Then the process continues past the joining gateway.

Note that a parallel gateway can have both fork and join behavior, if there are multiple incoming and outgoing sequence flow for the same parallel gateway. In that case, the gateway will first join all incoming sequence flow, before splitting into multiple concurrent paths of executions.

An important difference with other gateway types is that the parallel gateway does not evaluate conditions. If conditions are defined on the sequence flow connected with the parallel gateway, they are simply neglected.

Figure 37. Graphical Representation

Table 49. Specific attributes
Attribute Name	Description
none

Call activity (subprocess)

BPMN 2.0 makes a distinction between a regular subprocess, often also called embedded subprocess, and the call activity, which looks very similar. From a conceptual point of view, both will call a subprocess when process execution arrives at the activity.

The difference is that the call activity references a process that is external to the process definition, whereas the subprocess is embedded within the original process definition. The main use case for the call activity is to have a reusable process definition that can be called from multiple other process definitions.

When process execution arrives in the call activity, a new execution is created that is a sub-execution of the execution that arrives in the call activity. This sub-execution is then used to execute the subprocess, potentially creating parallel child execution as within a regular process. The super-execution waits until the subprocess is completely ended, and continues the original process afterwards.

Figure 38. Graphical Representation

Table 50. Specific attributes
Attribute Name	Description
LoopType	Selection of the loop type. See Multi Instance to know more about loops
Sub Process Reference	Select the subprocess to be called within the call activity
Sub Process Reference (RT)	Use a backend expression to evaluate the sub process reference dynamically at runtime. Example: The expression ${modelManager.findLatestDefinitionKeyByModelId(String modelId)} gets the latest model definition for the given model Id.
In	Map input data to be passed from the parent (current) process to the subprocess while starting the subprocess
Out	Map output data to be passed form the subprocess to the parent process after the subprocess has finished

Subprocess

A subprocess is executed within the scope of the parent process.

Figure 39. Graphical Representation

Table 51. Specific attributes
Attribute Name	Description
LoopType	Selection of the loop type. See Multi Instance to know more about loops

Text Annotation

The Text Annotation is for documentation purpose only, it’s not evaluated by the engine. Use it to add textual explanations to an element of the process model. In contrast to the Documentation property of an element, the text annotation is also visible on the graphical representation of the process model.

Figure 40. Graphical Representation

Table 52. Specific attributes
Attribute Name	Description
Text	Text annotation displayed in the process model.

Association

An association is represented with a dotted line. It is used to associate an artifact or text to a flow object, and can indicate some directionality using an open arrowhead (toward the artifact to represent a result, from the artifact to represent an input, and both to indicate it is read and updated). No directionality is used when the artifact or text is associated with a sequence or message flow (as that flow already shows the direction).

edoras one currently only supports undirected associations

Figure 41. Graphical Representation

Table 53. Specific attributes
Attribute Name	Description
none

3.6.4. Role elements

Horizontal Pool

Represents the organizational boundaries of a process, typically separating different organisations. A pool contains one or more lanes (like a real swimming pool). One process has to be executed within a pool. If the end-to-end process includes multiple pools, each pool has it’s own process flow. Communication between pools is handled by Message Flows. The horizontal pool in edoras one represents the system boundaries of edoras one in the mentioned orientation.

Figure 42. Graphical Representation

Table 54. Specific attributes
Attribute Name	Description
isExecutable	Indicates if this pool is executable.

Vertical Pool

Represents the organizational boundaries of a process, typically separating different organisations. A pool contains one or more lanes (like a real swimming pool). One process has to be executed within a pool. If the end-to-end process includes multiple pools, each pool has it’s own process flow. Communication between pools is handled by Message Flows. The vertical pool in edoras one represents the system boundaries of edoras one in the mentioned orientation.

Figure 43. Graphical Representation

Table 55. Specific attributes
Attribute Name	Description
isExecutable	Indicates if this pool is executable.

Collapsed pool

A collapsed pool hides internal detail from the viewer. It’s used to visulaize communication between the mail pool and an external system / organization that is not in the scope of the current project. The collapsed pool has no impact at execution time.

Figure 44. Graphical Representation

Table 56. Specific attributes
Attribute Name	Attribute Type
Description	none

Lane

Used to organise and categorise activities within a pool according to function or role, and depicted as a rectangle stretching the width or height of the pool. A lane contains the flow objects, connecting objects and artifacts.

Figure 45. Graphical Representation

Table 57. Specific attributes
Attribute Name	Description
none

Message Flow

A Message Flow is represented with a dashed line, an open circle at the start, and an open arrowhead at the end. It tells us what messages flow across organizational boundaries (i.e., between pools). A message flow can never be used to connect activities or events within the same pool.

Figure 46. Graphical Representation

Table 58. Specific attributes
Attribute Name	Description
none

3.6.5. Multi Instance

edoras one supports the creation of multiple instances of several BPMN 2.0 elements (Human Task, Call Activity, Embedded Subprocess and all Activities in the section Service Tasks of the edoras one palette). Multi-instancy is configured within the process model.

To specify multi-instancy select the corresponding type parallel or sequential.

If you chose parallel, all instances of the element are created at once, when the execution arrives at the activity. If you choose sequential, the next instance of the activity ist created, when the previous activity was completed.

Table 59. Multi-instance attributes
Attribute Name	Description
Loop collection	A varialbe from the variable hierarchy that holds a list of elements. All elements of the list are processed, that means, the platform will generate one instance per list element
Loop element variable	a copy of the current list element. If you want to modify the variable, write the new value to the original list element since the loop element variable is not merged with the original one, once the execution is terminated.
Loop element index variable	The name of the variable where the current list index is stored.
Loop cardinality	An expression that evaluates to an integer which determines the number of instances to be created if you do not use a list for iteration.
Completion condition	A boolean expression do define a condition, to terminate the multi-instancy. As long as the expression evaluates to true, a new instance will be created.

3.7. Keyboard shortcuts

Table 60. Keyboard shortcuts supported by the property panel
Name	Description
Up	Navigate to above property in the panel.
Down	Navigate to below property in the panel.
ENTER	To open editors and closing/committing entered value for inline editors.
SPACE	To open inline editors / toggle boolean values.
ESC	To close inline editor without committing the values.
F2	To open editor for editing selected attribute.

Table 61. Keyboard shortcuts supported by the treeview dialog editor
Name	Description
ALT + 1	Selecting a New radio button.
ALT + 2	Selecting a Reference radio button.
ALT + 3	Selecting a Url radio button.
ALT + 4	Selecting a Remove Reference radio button.
SHIFT + F	Switch to Find(Search) mode in reference panel.
SHIFT + T	Switch back to Treeview mode in reference panel.
Up	Navigate to above node in tree.
Down	Navigate to below node in tree.
Left	Collapse folder.
Right	Expand folder.
ENTER	Select the current model.

Table 62. Keyboard shortcuts supported by the complex dialog editor
Name	Description
INSERT	Adding a new row.
DELETE	Deleteing a selected row.
CTRL + up	Moving selected row up.
CTRL + down	Moving selected row down.
ENTER	Editing a selected cell.
TAB	Selecting next cell.
F2	To open editor for editing the selected cell.

3.8. Designer Usability hints

The designer provides various usability hints.

3.8.1. Alignment of shapes

Using Middle shape_align_middle and Center shape_align_center toolbar buttons we can align shapes horizontally or vertically.

Click the link to see demo.

3.8.2. Resizing of shapes to same size

Using Same size shape_align_size toolbar button we can resize all selected shapes to the same size.

Click the link to see demo.

3.8.3. Auto layout of connectors in process designer

Using Auto Layout shape_auto_align toolbar button we can auto layout the connectors (sequence flows) in the process diagram.

3.8.4. Creating dockers and removing dockers

We can create and remove dockers in 2 ways:

By using Add Docker and Delete Docker toolbar buttons
By using mouse pointer directly on connecting shapes.

Click the link to see demo.

3.8.5. Changing the position of shapes

Using Change the position of shapes shape_translate toolbar button we can move the shapes horizontally or vertically.

Click the link to see demo.

3.8.6. Transform shape

Using Transform shape feature we can transform a shape to another type belonging to same group.

Click the link to see demo.

3.8.7. Validating a process

Using Validate Process checker_syntax toolbar button we can find if there are any errors in the process.

Click the link to see demo.

3.8.8. Deleting of shapes

Using Delete all selected shapes cross toolbar button we can delete all selected shapes. We can also delete selected shapes using Del key.

Click the link to see demo.

3.8.9. View preview in form designer

Using View preview edorasform_preview toolbar button we can view preview of the form.

3.8.10. Import BPMN 2.0 XML in process designer

Using Import BPMN 2.0 XML import toolbar button we can import process from a BPMN 2.0 XML into the process diagram.

3.8.11. Export/Import localization text

Export/Import localization text epc_export toolbar button supports exporting of all localized texts for a given model and importing of modified localized texts into the given model.

3.8.12. Compare revisions

Compare revisions compare toolbar button can be used to compare the revisions of the model to view the changes done between revisions.

3.8.13. Drop shape on connectors / remove shape from connector

When we drop a new shape on a connector which is already connecting 2 other shapes, the connector automatically splits to accomodate the new shape.

Similarly, if we delete a shape which is already connected to two other shapes, the connectors automatically rejoin.

Click the link to see demo.

We can quickly add and connect shapes to existing shapes using the quick shape menu.

Click the link to see demo.

3.8.15. Editing shape property in process/from designer

We can directly edit some of the shape properties like name in the process editor, and label, description and value in the form editor.

Click the link to see demo.

3.8.16. Using label expression in process designer

We can define a custom label expression for shapes, so that corresponding values are displayed as label on the shapes

Click the link to see demo.

3.8.17. Resizing of shapes using mouse

Using mouse pointer, we can resize the shapes.

Click the link to see demo.

3.9. Expressions

edoras one can evaluate expressions in both the frontend (i.e. in the browser) and in the backend (i.e. in the server). Expressions can be used in a number of ways in the edoras one application, for example:

to create a binding between a form field and work object data
to modify the state of form fields dynamically in response to user input (e.g. field visibility)
to populate a mail template before the mail is sent
to control the execution flow in a process execution
to execute method calls on the server
…

3.9.1. Frontend expressions

Form binding expressions

Forms are used to display and edit the data of underlying work objects. The work object data and the form definition are fetched from the server, and the expressions used within the form definition are then used to link the form fields with corresponding data. For editable fields, any changes made are reflected in the underlying work object data, which is sent back to the server to be persisted when the form is submitted:

Form data binding expressions are placed between two sets of curly braces, e.g. {{expression}}, and are set using a form field’s Value attribute:

The Value attribute of most form fields may only be bound to a single expression, and this may not be preceded or followed by other text.

The only exception to this rule is the output field, which doesn’t bind to a single value, but instead uses form expressions embedded within a rich text template to create dynamic textual output.

Simple variable bindings

A simple value name in double curly braces (e.g. {{value}}) is used to link to the corresponding variable in the current work object. If the work object variable doesn’t exist when the form is opened then it will be created automatically.

Bindings to other hierarchy work objects

A work object in edoras one is typically part of a hierarchy, where work objects are linked together in a tree of parent/child relationships. For example a case typically serves as a container for other work objects (tasks, running processes, documents etc.). Form binding expressions can also be used to access the values from related work objects in the work object hierarchy. This is done be preceding the variable to be accessed by a qualifier (e.g. {{root.value}}):

The following qualifier keywords are currently supported:

parent	the parent of the current work item
root	the root of the current work item hierarchy
self	the current work item
$this	the form. When we use a subform widget it would be the subform itself.

As an example, if we start a process within a case then the process’s parent work object will be the case. A form task created by that process will have the process work object as its parent:

Figure 47. Example work object hierarchy

In this case {{root.name}} will bind to "Example case", {{parent.name}} will bind to "Example process" and {{name}} will bind to "Example task".

Init forms for tasks and processes only support parent variables update. That means that is not possible to update the case variables using the expression root.

Bindings to other global objects

currentUser: The object of the current user logged in the application, which provides its properties like id, name e.g {{currentUser.id}}

Bindings to global functions

isUserInGroup(userId, groupId)

The result of this expression will become true if the user is member of the provided group.

Parameters:
- userId: the id of the user.
- groupId: the id of the group.

This expression is executed asynchronously, that means that it will be "false" until the response from server is success.

isUserInGroups(userId, groupIds)

The result of this expression will become true if the user is member of one of the provided groups.

Parameters:
- userId: the id of the user.
- groupIds: an array of group id’s.

This expression is executed asynchronously, that means that it will be "false" until the response from server is success.

isUserInAllGroups(userId, groupIds)

The result of this expression will become true if the user is member of all of the provided groups.

Parameters:
- userId: the id of the user.
- groupIds: an array of group id’s.

This expression is executed asynchronously, that means that it will be "false" until the response from server is success.

Formatting dates in frontend expressions

When not being used to create a binding between a form field and a work item attribute (e.g. when used in the output form widget), frontend expression that resolve into a date can have an additional format string that defines how the date is formatted. To do so append the format string to the binding expression, for example:

{{anyBoundDate | date:'MMM/dd/yyyy'}}
{{anyBoundDate | date:'dd-MM-yyyy'}}

If no format string is explicitly specified then yyyy-MM-dd is used.

The following tokens are allowed:

Token

Description

yyyy

4 digit representation of year, e.g. 0001, 2010

2 digit representation of year, padded (00-99), e.g. 01, 10

MMMM

month name long (always in English): January-December

MMM

month name short (always in English): Jan-Dec

month of year (two digit): 01-12

month of year (no leading zero): 1-12

day of month (two digit): 01-31

day of month (no leading zero): 1-31

EEEE

day name long (always in English): Sunday-Saturday

EEE

day name short (always in English): Sun-Sat

The format string can contain literal values which need to be quoted with single quotes. Make sure that you escape the single quotes that denote a literal value. In order to output a single quote, use two single quotes in a sequence:

{{anyBoundDate | date: '\'day\' d \'of\' MMMM \'in the year\' yyyy'}}
{{anyBoundDate | date: '\'Today it\'\'s\' dd/MM/yyyy'}}

It’s also possible to use the age filter in order to calculate the elapsed time from provided date until current date. The elapsed time can be calculate in ages or days.

{{anyBoundDate | age}}
{{anyBoundDate | age: 'd'}}

More complex frontend expressions

When not being used to create a binding between a form field and a work object attribute, that is when not setting value property on most of the widgets, we can use more complex expressions like arithmetic or logic operations.

You can use this kind of expressions in runtime properties (like Editable(RT) or Visible(RT) ), query, default, or in the value of the output text.

Arithmetic operations

{{ (number1 + number2) * number3 }}
{{ number1 / number2 }}

Text concatenation

{{ text + ‘_end’ }}

Logic operations

{{ (boolean && otherBoolean)  &&  ( text + _‘endText’ )}}

Assignment operation: This will create a variable in the data model of the form. For example, in the example bellow if you use this expression in an output text, the variable modelValue will be saved, the result of the expression would the the result of the operation after the =.

{{ modelValue = number1 + number2 }}

Subform with multiple elements special expression keys: When we use subform or multi type subform with multiple elements we can make use of some special expressions:

Key

Result type

Description

$index

number

iterator offset of the repeated element (0..length-1)

$first

boolean

true if the repeated element is first

$middle

boolean

true if the repeated element is between the first and last

$last

boolean

true if the repeated element is last

$even

boolean

true if the position $index is even

$odd

boolean

true if the position $index is odd

We can, for example, retrieve the value of the previous item, having a subform with "mySub" value, the last item would be {{mySub[$index-1]}}

Accessing arrays: Some widgets saves an array of items (Search button , Autocomplete with multitag, subform with miltiple elements, etc.)

You can access the value of an element through an expression model, for example, having a search button with {{myResult}} value, and a number widget with {{myIndex}}. You can use an expression like {{myResult[myIndex]}} to retrieve an item of the array.

3.9.2. Backend Expressions

Expressions can also be executed on the server, for example within the process models. Server-side expressions are called backend expressions. A much wider range of expressions is possible than in frontend expressions the expressions may also have side-effects within the system (for example causing an e-mail to be sent). As well as accessing data from the work object hierarchy, backend expressions support additional functionality such as accessing work objects outside of the immediate hierarchy, predefined function calls and bean method calls.

There are two basic expression types:

value expressions: have the form #{value.property} and resolve to a value
method expressions: have the form #{bean.method(value)} and result in a method invocation

The full backend expression language is part of the EE6 specification and only an brief overview will be provided here. For a full description of the expression language syntax please refer to the EE6 specification.

Accessing work objects

As in the frontend, qualifiers can be used to traverse the work object hierarchy, although there are more options available in backend expressions. qualifiers can also be chained (e.g. #{process.parent.name}):

The following qualifier keywords are currently supported:

self: the current work item (the default if no work object is explicitly specified)
case: the top-most parent case to which the current work object belongs
parentCase: the nearest parent case to which the current work object belongs
process: the top-most parent process to which the current work object belongs
parentProcess: the nearest parent process to which the current work object belongs
root: the root of the current work object hierarchy
parent: the direct parent of the current work object

Backend attribute values

Simple attribute names can be used to access work object attributes in backend expressions in the same way as in frontend expressions (see Frontend expressions).

To access attributes, simply use the attribute name: #{case.name}

One significant difference between frontend expressions and backend expressions is that the work object attributes accessible in the frontend may have been pre-processed by the server so that the attribute values are in a form that makes more sense in the client’s context. With backend expressions this processing is not performed so you will be working with raw work attributes.

As an example, state is represented in a work object by an instance of the State class. In the frontend , the expression {{state}} will be bound to the name field of this object (e.g. "ACTIVE"). The conversion from a State object to the state name string has already been performed by the server.

The corresponding process binding, #{state} resolves to the underlying State object, which if it is used in a string context will be converted to a string literal, e.g. "[State@51d838d9 name = \'ACTIVE']". To access the plain name ("ACTIVE") we can use a java bean property expression: #{state.name}.

For a description of common work object attributes, refer to Common attributes.

Automatic work object ID conversion

Work objects are referenced using IDs, and in a backend expressions it is often useful to access not the ID itself but the referenced work object. To support this use case, an expression that resolves to a work object ID will automatically be converted to the corresponding work object instance as needed.

For example the expression #{ownerId} will resolve to the owner ID, but if we then extend the expression (e.g. #{ownerId.name} then the ID will be converted to the corresponding work object, and the name attribute from this work object will be returned.

As access to other work objects linked from a work object using IDs is so common there are also some shortcut expressions to access this information directly:

Table 63. Predefined work object expressions
Expression	Type	Description
#{owner}	User work object	the work object’s owner
#{assignee}	User work object	the work object’s assignee
#{initialAssignee}	User work object	the work object’s initial assignee
#{previousAssignee}	User work object	the work object’s previous assignee
#{candidateUsers}	List of user work object	the work object’s candidate user list

Resolving hierarchy variables

A major difference between frontend expressions and backend expressions is the visibility of work object variables within the work object hierarchy. With frontend expressions, accessing parent or root variables requires explicit use of the appropriate qualifier (e.g. parent.attribute).

With backend expressions, however, this is not always required. In the server, variables from parent work objects in the hierarchy are also visible in the child work objects. If a parent and child both have variables with the same name then only the child variable will be visible in the child work object.

For example, take the following work object hierarchy:

If we are resolving variables in the task context, then the expression #{case.message} will resolve to "Case message".

The expression #{process.message} will also resolve to "Case message" the process work object will inherit the message value from its parent (the case).

The expression #{message} will resolve to "Task message", however, as the variable inherited from the case has been hidden by a more local value.

Bean resolution

Backend expressions can also be used to access java beans, either to make method calls (#{beanName.method()}) or to access bean properties (#{beanName.property}).

For security reasons it is obviously not a good idea to allow access to all beans within the server, and so edoras one only allows access to a specific set of approved bean names.

Predefined functions

Backend expressions also support a number of predefined functions. As with bean resolution, the functions provided by a given edoras one installation can be configured, so the list of available functions may vary from system to system.

The following functions are provided by default:

now(): returns the current date and time
formatDate(Date date, String pattern): returns the provided date formatted according to the provided pattern. When input parameters are null or empty throws IllegalArgumentException.
formatDateNullSafe(Date date, String pattern): returns the provided date formatted according to the provided pattern. When input parameters are null or empty returns empty string.
formatType(Type type, boolean lowerCase): returns the provided type formatted as a String. When type input parameter is null throws IllegalArgumentException.
anyOf(Boolean... operands): returns true if any of the provided booleans is true, false otherwise
allOf(Boolean... operands): returns true if all of the provided operands are true, false otherwise
concatenateListWithList(List<T> base, List<T> toAppend): returns a list that is the concatenation of the given two lists
concatenateListWithElements(List<T> base, T... toAppend): returns a list that is the concatenation of the given lists and the given elements
extractValuesFromCollectionOfMaps(Collection<Map<String, T>> maps, String mapKey, boolean skipNullValues): returns a collection of map values for the given key from the given collection of maps

Identity Manager bean

The predefined bean #{identityManager} provides functions related with the group management.

The available functions of this bean are:

getUsersOfGroup(GroupId): returns the list of users of a given group.
getUsersOfGroups(Collection<GroupId>): returns the list of users of a collection of groups.
isUserInGroup(UserId userId, GroupId groupId): returns a boolean which value is true if the given user belongs to a given group.
isUserInGroups(UserId userId, List<String> groupIds): returns a boolean which value is true if the given user is member of at least one group in the list, false otherwise. In case of empty list false is returned.
isUserInAllGroups(UserId userId, List<String> groupIds): returns a boolean which value is true if the given user belongs to all groups in the list, false otherwise. In case of empty list false is returned.

Model Manager bean

The predefined bean #{modelManager} provides functions related with the models.

findLatestDefinitionKeyByModelId(String testModelId): Returns a string which contains the latest active definition key by the given model id.

System properties in backend expressions

The expressions using system properties with dots in the name are supported in the following way, for the example for the property mail.smtp.from:

#{systemProperties['mail.smtp.from']}

3.9.3. Common attributes

Work object attributes

A number of predefined attributes are available on every work object:

Table 64. Predefined work object attributes
Expression	Type	Description
name	String	the work object’s name
description	String	the work object’s description
state	String	the work object’s state
type	String	the work object’s type
ownerId	User ID	the work object’s owner
assigneeId	User ID	the work object’s assignee
candidateUserIds	List of group IDs	the work object’s candidate users
candidateGroupIds	List of group IDs	the work object’s candidate groups
creationTime	Date	the work object’s creation time
updateTime	Date	the work object’s last update time
dueTime	Date	the work object’s last due time
priority	Number	the work object’s priority

User attributes

The following attributes are defined in user work objects:

Table 65. Predefined user attributes
Expression	Type	Description
login	String	the user’s login name
name	String	the user’s display name (full name)
firstName	String	the user’s first name
lastName	String	the user’s surname
address	String	the user’s address
phone	String	the user’s telephone number
mobile	String	the user’s mobile telephone number
email	String	the user’s email address
language	String	the user’s language
homeUrl	String	the user’s home URL
notes	String	the user’s profile notes
memberGroups	List of group IDs	the groups ids which the user belongs to

3.10. Localization

edoras one supports five languages: English, German, French, Spanish and Italian. When modelling is possible to define different languages for tasks, forms widgets, cases, etc.

In this section you can find how to localize your application models.

3.10.1. Localize applications models

In order to set the supported languages of the application model, firstly they should be defined in the 'Browse' view. There you can set a primary language and various secondary languages.

If your language is not maintained in a particular App model, it defaults to the primary language defined.

3.10.2. Localize case models

In order to localize the cases, the modeller should navigate to the 'Browse' view and click in 'Localize' action button. The name and description of the case can be set in the languages defined in the application model.

3.10.3. Localize process models

In order to localize the processes, the modeller should navigate to the 'Browse' view and click in 'Localize' action button. The name and description of the process can be set in the languages defined in the application model.

3.10.4. Localization in VIS

There are some attributes of VIS elements which can be also localized, for example the labels or the task names can be set in the languages defined in the corresponding App model. To see the localized attributes in the attributes panel, the language must be selected at the top-right of the panel. A list with the application model languages will be displayed:

When a language is selected, a new attribute for each attribute which can be localized will be added in the attributes list:

Moreover the design and preview form will be displayed in the language selected in the menu.

3.11. Glossary

app: an app is a container for a collection of models that define a specific workflow.
backend expression: a backend expression will be evaluated in the server, for example to populate a mail template before it is sent.
dashboard: a page in the edoras one application where work objects can be found, displayed and manipulated. Each dashboard manages related work object types that play a given role within the system.
definition: when a model is deployed, a definition is created in the system. Definitions describe the behaviour of the system as seen by a normal user.
deployment: the process of converting the models into definitions to create an executable workflow.
document placeholder: a backend expression identified by a key in a document model. Used to insert dynamic content into documents.
expression: an expression can be used to access content or trigger specific behaviour at runtime. Two types of expressions are used: frontend expressions and backend expressions.
form: a form is a graphical layout of fields that may be bound to work object data to allow this data to be displayed or modified within the edoras one application.
form widget: a form widget is a type of form field, e.g. text form widget, date form widget, number form widget. The form field represents the single element on the form whereas the form widget represents the type of these single elements. As such the form widget defines the look and behaviour of the corresponding form fields.
form field: a form field is a single element on a form. The user interacts with the form field, most of them are interactive but some of them are read-only.
form field part: a form field is composed of different graphical parts: a label, a control, a description, a required indicator. The user interacts with the control part only.
frontend expression: a frontend expression will be evaluated in the browser, for example to bind form fields to work object data.
model: a description of a workflow component which can be deployed together with other models to create a executable workflow in edoras one
process: a process is a workflow definition, described using a BPMN 2.0 model and executed within edoras one. It typically defines the automated and manual tasks that must be performed to complete the workflow.
system app: a special App that can only be seen by the administrator. It contains the models that are required for the correct operation of edoras one.
task: a task is a single action within a workflow, and may be either automated (a service task) or manual (a user task).
work object: an item that can be created or manipulated in edoras one. Different types of work object are supported. The work object types are typically grouped according to their role within the system and accessed through dashboards.

4. edoras one Modeler Tutorial

4.1. Intro

This step-by-step tutorial will help edoras one modelers to get started with modeling Apps for the edoras one platform.

It’s a good idea to have read the basic edoras one intro (general guide) as well as the edoras one user guide, which can be found here: http://documentation.edorasware.com

4.1.1. What you will learn

By executing this tutorial step by step, you will learn how to create your own App, which includes the following steps and learning content.

Basic modeling techniques

Creating case models
Design forms
Design processes
Creating ad-hoc task models
Creating email templates
…

Advanced modeling

4.1.2. Tutorial App

In this tutorial you will create a new App, which will handle a travel request. A person in need of traveling will create a new travel request and a travel agent is organizing the necessary bookings for the traveling.

The request process is built step by step by adding approvers to the process, modeling a feedback-loop between travel agent and requestor and by adding mail tasks to send out information once the travel has been organized.

Everything around the travel request is modeled within a case, so we are able to attach any necessary information like reservation information, vouchers and the like directly to the case as well as having an overview of everything going on while managing the travel request.

4.2. Basic Travel Request Case and Form

In this chapter you will create the Tutorial App with a new form and case model, deploy it and test the new case model within the user dashboard.

4.2.1. Creating a new App

In order to get started, go to the modeler dashboard and hit c or click the Create button in the menu and choose Create App.

Type Tutorial App as the name for the App.

Select English as the primary language for the App.

Select any other languages you want as secondary languages.

As an App can be modeled in several languages, you specify a main (primary) language for the App, which will act as the default language, if not all elements are translated. You will be able to design forms and processes with all languages you selected (primary will be default). Now click Create and navigate to the newly created App by clicking on the link in the green success message you see on the top of the screen.

4.2.2. Creating a form to start the travel request

Let’s create a first form by typing again c (shortcut) or clicking the Create button in the menu. Now let’s choose Create Form Model and make sure the Tutorial App is selected as the parent App (meaning the new form model will be created inside that App).

Type Travel Request Form as the name for the new form model and click Create and design in order to create the model and directly go to the form designer.

Getting familiar with the basics of the form designer

The form designer consists of three parts; on the left you will find the shape repository, the main canvas for the form design in the middle and on the right hand side you find the attributes of the currently selected widget (component) of the canvas.

You can add a new widget to the canvas by simply drag & drop it from the shape repository to the canvas. During the drag & drop procedure you will get feedback by the responsive layout manager on where the widget can be dropped.

The layout is responsive having twelve slots you can use to arrange your widgets. By using the handles on the left or right side of a widget, you can define the span of the widget from one up to twelve slots.

The shape repository has several sections to choose from. Use any predefined widgets in order to not having to care about bindings and any other technical issues. The widget section on the other hand has a collection of all available widgets which can be used by configuration through the attributes section.

Add name and description widgets

To start with the design, let’s use two predefined fields; the name and description. Those fields are always available; each work item is supporting them.

Now drag and drop the name and description field from the predefined bindings section on to the empty form. Rename the name label to Travel subject and the description label to Travel notes.

Add traveling locations

Now let’s add two fields to enter the origin and destination of the travel. There is no predefined field for that, so let’s use the Text field from the Components section. Name the first one Origin and the second one Destination. By dropping the second field onto the first one will split up the row into two parts and now having two fields in the same row, both spanning six slots.

Instead of navigating through the shape repository, you can also use the filter functionality to quickly find a specific widget. Click the filter icon in the top right corner of the Shape repository and type the name of the widget into the search field (e.g. text).

By selecting a field and clicking the red star icon, it will make the fields mandatory. Do this for both Fields. You can do the same by clicking the Required attribute on the right side.

Getting familiar with the data model behind work items

Before we can define the data bindings for the new fields, let’s have a short look on how data is stored and managed within edoras one.

The basic infrastructure to manage anything within edoras one is called work item. A work item is an object from a particular type (e.g. a case, a task, a process or a document), it’s behavior is driven by the type and it’s model (e.g. a process work item is driven by it’s process model which in our case is modeled with BPMN 2). Besides the behavior, every work item is capable to store arbitrary data, called variables. Variables are holding different types of data, e.g. text, numeric value, a date or a boolean value. Variables can even hold lists of data or maps or even lists of maps including unlimited nesting.

In order to enter or show data of work items, the variables can be mapped (bound) to fields.

Define data bindings for the fields

The next step is to set the binding for the newly added fields. Double-click the field or go to the Value attribute on the right side. Bindings are telling the form engine where to save and load the data for a particular field.

Let’s save the origin in a variable called travelOrigin and destination in a variable named travelDestination, respectively. Bindings are specified using expressions, which start with a double curly brace {{ and end with a double curly brace }}.

If we don’t specify any prefix to the variable name, the data is stored / retrieved from the very work item the form is used for.

Add date pickers for the outward and return trip dates

Now let’s add two new fields to pick the starting and ending date for the travel. Drag and drop two Date fields to the form and name them Outward trip date and Return trip date, respectively.

Make the fields mandatory and set the bindings to {{outwardTripDate}} and `{{returnTripDate}}.

Add validation to the date pickers

As we want to make sure there is no date selected in the past, let’s add a validation to the date picker.

You can do so by selecting the date field and then click on the Minimum date attribute on the right side under Specific attributes. Select a relative date validation by choosing Today + 0 Days.

For the Return trip date we also want to add a validation. Here we want to ensure that the selected date is not smaller then the Outward trip date. To achieve this, we simply add {{outwardTripDate}} to the Minimum date attribute of the Return trip date widget.

Now save the form by clicking the Save icon in the designer menu on the left.

4.2.3. Create case model

Now switch back to the browser tap where you created the new form (not the form designer) and click the Create button once again and select Create case model.

Fill out the case model form:

Set Travel Request as the name
Choose the Travel Request Form as the init and the work form of the case
Everything else can be left as it is by default, we will adapt that later

Now click Create to create the new case model.

4.2.4. Deploy the App

Done! We have our very first version of the Tutorial App, ready to be deployed and used.

Click the Tutorial App link from your previous, green success message or the link within the header of the current case model in order to navigate to the Tutorial App.

In the App, you should now see two models, the Travel Request case model and the Travel Request Form model.

On the right side menu you can select Deploy which opens the deploy dialog. Navigate to the end of the form and click OK to deploy the App and make it available within the user dashboard so we can now test it.

4.2.5. Test the App

In order to test the newly deployed App, we switch back to the user dashboard. You can do so by manually selecting the User dashboard from the menu of dashboards or use the d shortcut. While modeling and testing, it is also a good practice to have two tabs open constantly, one with the user dashboard and one with the modeler dashboard.

Once in the user dashboard, click Create or type c to open the creation dialog. Select Create Case and choose Travel Request from the selection menu.

Fill out the request init form as we designed it. Please note the validations and within the date picker, specifically see that you will not be able to enter a date earlier than today.

Click Create to start the new case. You will see the newly created case with the same form as we used it for both, the init and the work form. So you will be able to change any data and click Save in order to change the data for that case.

On the right side you will find available actions for the current work item (a case currently). The top right area shows the available views of the work item.

Actions from top to bottom:

Assign: let’s you specify the owner and current assignee of the work item
Share: let’s you share the work item with one or more groups
Start Process: start an ad-hoc process within the current case
Archive: closes the current work item and archives it

Views from left to right:

Search: navigates to the list of children of the current case where you can find open tasks, documents or whatever the current case is holding
Browse: navigates to the main work form of the current work item
Comments: navigates to the comment section of the current work item where you can see all existing comments as well as add new comments or reply to existing ones
Edit Entity: only available for modelers, shows a generic view with all data of the current work item and the ability to change it or even add new variables
Edit Entity JSON: a JSON representation of the current work item, which can also be modified (be very careful in doing so as you could break data of the work item by modifying it’s JSON representation)

4.3. Basic process modeling

In this chapter you will learn how to create your first process and attach it to the previously created case model in order to start it automatically once a new travel request is created.

4.3.1. Create new "Travel Request Process" model

Switch back to the modeler dashboard (either through the dashboard switcher or by going to your second tab with the modeler dashboard still open).

Choose the Tutorial App if not yet opened and click Create or hit c. Now let’s choose Create Process Model and enter Travel Request Management Process as it’s name and click Create and Design in order to create the process model and directly open it in the process modeler.

4.3.2. Getting familiar with the process modeler

The process modeler is quite similar in it’s basic functionality as the form designer. On the left hand side you find the shape repository with several sections where you can choose process elements from, the middle area is the main process canvas where you design the process and the right hand side is showing the attributes of the currently selected element in the process canvas.

You can add elements to the process by simply drag and drop them from the shape repository onto the canvas.

Hint: as you start modeling processes, there is a very handy feature to make more space in your current process model, the spacing tool:

Activating it will allow you to simply extend (enlarge) the process model or make it smaller. Give it a try once you have some elements on the canvas and make yourself familiar with that feature. Simply turn it off by clicking it once again and deselecting it.

4.3.3. Add a pool and lanes to the process

Let’s start the process model with adding a pool and lanes to it, although this is optional in BPMN 2, but is a good practice in order to visualize the different roles and involved people and groups in the process.

Go to the Roles section in the shape repository, drag and drop a Pool onto the canvas and name it Travel Request Process. A single lane has been added automatically, double-click its label (called Lane) and rename it to Requestor.

Now let’s add a second lane for the travel agent managing the travel request. Select Lane from the Roles section of the shape repository and drag it to the bottom part of the pool, which will add it as a second lane below the existing one. Name it Travel Agent. Using the spacing tool mentioned before, it’s easy to make the lanes smaller or larger according to the needs.

4.3.4. Model two user tasks as the first version of the process

Now we created two lanes representing two different types of involved people in the process, the requestor actually creating the travel request and the travel agent, responsible to manage the travel.

Let’s add a start event to the process by dragging the Start event element from the Execution section of the shape repository onto the Requestor lane. As long as that element is selected, you should see the fast-modeling menu right next to the element. Click the user symbol in order to add a user task right after the start event. Name it Manage Travel Request, click on the user symbol again and name the next task Review Travel Bookings and then click the thick rounded end event in the fast-modeling menu.

Done! We have our very first process with a start event, two user tasks and an end event.

Now let’s move the tasks into the right lane by simply moving them. Move the Manage Travel Request task into the second lane, as it should be done by the travel agent. Make use of the spacing tool in order to add or remove space between lanes, elements, etc.

4.3.5. Save process model and attach it to the case model

Now save the process model by clicking on the save action in the menu bar (ignore the warnings for now, we will add task forms later) and go back to the browser tab with the process model within the Tutorial App (not the designer window).

Navigate to the Tutorial App and select the travel request case model. In the Autostart Processes selection choose the newly created process model and save the case model again.

4.3.6. Re-deploy and test the App

We now created a first, yet simple process model and attached it to the existing case model. We can now re-deploy the App by using the Deploy action as we did before and switch to the user dashboard in order to test the changes we did.

After successfully deploying the Tutorial App again and switching to the user dashboard, click Create again and select Create Case. Select the Travel Request template, fill out the form and start the next travel request case.

Did you note the gray badge in the left top corner of the children view button? It shows you that there is one child work item of the current case which is the first task being created by the process.

Click the children list view to see that task. The open task should be named Manage Travel Request and behind it you should see the name of the travel request case (the same as within the header).

Navigate to the task by clicking its name. It will take you to the work form of that user task. You can still see the case in the header section of the task and use it for the navigation back to the case or you can also use the browser-back button to go back. Navigating to the task means, selecting it as the current work item. As you probably noted, this will change the available views and actions, always reflecting the possibilities of the currently selected work item.

The user task has a default form with the name of the task and a description field. But let’s have a look at the different options we got working with the task. There is a new view, called Preview, selecting it will show you the process with a red border around the current task.

edoras one Documentation

1. edoras one Overview

1.1. What is edoras one?

1.2. What is the main concept behind edoras one?

1.3. What is the concept behind "cases"?

1.4. What can I use edoras one for?

1.4.1. Approval Processes

1.4.2. Help Desk

1.4.3. HR

1.5. What license do I need to work with edoras one?

1.6. What are the supported runtimes for edoras one?

1.7. Architecture Overview

2. edoras one User Guide

2.1. Basic application layout and navigation

2.1.1. Dashboards

2.1.2. List view

2.1.3. Work item page

2.1.4. Work item views

Browse view

Search view

Comments view

Preview view

Edit entity view

Edit entity JSON view

2.1.5. Bookmarking pages

2.1.6. Keyboard shortcuts

2.2. Dashboards

2.2.1. User dashboard

2.2.2. Modeler dashboard

2.2.3. Admin dashboard

2.2.4. Management dashboard

2.3. User Profile

2.3.1. Change your email address

2.3.2. Change your language

2.3.3. Change your password

2.3.4. Deputies

2.4. Avatar

2.5. Search

2.5.1. Basic searching

2.5.2. More complex searching

Search terms

2.5.3. Sort terms

2.5.4. User expression

2.5.5. Date expression

2.5.6. Number expression

2.5.7. State expression

2.5.8. Type expression

2.5.9. Dashboard expression

2.5.10. String expression

2.5.11. Model expression

2.6. Glossary

3. edoras one Modeler Guide

3.1. Modeler Overview

3.1.1. App Models

3.1.2. edoras vis

3.2. Model types

3.2.1. Form model

3.2.2. Task model

3.2.3. Document model

Skeleton documents

Placeholder expressions

Referencing placeholders from a Microsoft Word document

Referencing placeholders from an Adobe PDF document

Microsoft Word Mailing support

3.2.4. Process model

3.2.5. Case model

3.2.6. Mail model

3.3. Working with models

3.3.1. Accessing the modeler dashboard

3.3.2. Importing App models

3.3.3. Models state

3.3.4. Deploying an App model

3.3.5. Moving models between App models

3.3.6. Duplicating App models

3.3.7. Sharing models

3.3.8. The System App

3.4. Actions

3.5. Form palette

3.5.1. Concepts

Form layout