edoras one Modeler Guide

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 work items in the user dashboard.

Models are created and edited in the modeler dashboard. When models are deployed, corresponding work object definitions are created. These definitions can be used in the user dashboard to create work objects of the new type (usually referred to as work items in the user context):

After a model has been deployed to create a definition it may still be edited, for example to add new functionality or to fix a problem, but the changes that have been made will only become active when the App is deployed again. You can easily see whether an App has outstanding changes by checking the App status (see Model state).

A number of different model types are available as described in the following sections.

1.1. App model

An edoras one App model is a container for the models that combine to define a specific workflow within edoras one.

To define a workflow, first an App model is created and then the different models can be added and linked together as required. When the models defining the workflow are ready, the App can be deployed to create the corresponding definitions which can then be accessed from the user dashboard to execute the workflow. Only a complete App can be deployed as the models in the App should all be consistent if the deployed workflow is to function as intended.

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

1.2. Case model

In the user dashboard, a case serves as a container for all work items related to a workflow, such as documents, process executions (with the resulting tasks), ad-hoc tasks etc. Variables in the case work item can also be used to store information that needs to be shared by different parts of the workflow.

The case model typically uses init and work forms to create and manipulate the shared workflow information, and also defines the workflow actions that can or must be performed.

A case model may either be an adaptive case model or a CMMN case model.

With an adaptive case model, processes, tasks or documents will either be added automatically to a new case when is created or can be added manually later.

With a CMMN case model, the case lifecycle is defined using a CMMN 1.0 model and can be much richer than for an adaptive case model, including automatic state changes, milestones, processes, tasks etc.

1.3. Task model

A task model is used to define a new type of user task, corresponding to an action that needs to be performed by a participant in the workflow. Examples are entering / updating data or confirming that an external action has been performed.

1.4. Document model

A document model is used to define a new type of document. A skeleton document can be defined which will be used as a template when a new document of the given type is created, and placeholder substitutions can also be defined to insert values from the current context into the skeleton document.

1.5. 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 the current 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.

1.6. Process model

A process model allows a full BPMN 2.0 process execution model to be defined, describing a sequence of tasks to be performed either by the system itself (system tasks) or by users (user tasks). Conditional paths in the process allow the workflow to contain different tasks depending on the specific case being processed.

1.7. Mail model

A mail model provides a template for emails 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.

2. Working with models

2.1. Accessing the modeler dashboard

All users that are part of the modeler group will be able to access the modeler dashboard. Please refer to the edoras one Administrator Guide for details on configuring group membership.

2.2. edoras vis

edoras vis is the built-in graphical modeler used to model BPMN 2.0 process models, edoras one form models and CMMN 1.0 case models.

The graphical modeler GUI consists of the following main areas:

The model editor panel contains the graphical view of the model being edited. New elements can be added to the diagram either by dragging them from the palette panel or in some cases using the contextual elements that appear when a model element is selected. The attributes for the selected model element are shown and may be edited in the attributes panel. The toolbar contains a number of useful tools for editing models, for example to insert more space into the middle of a model or to compare different model revisions.

2.3. 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.

2.4. Model state

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

Table 1. 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.

The current state of a model is shown in the header bar for the model:

2.5. 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.

2.6. 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.

2.7. 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.

2.9. 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. 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 2. 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 3. 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.

4. App model

An edoras one App model is a container for the specific models that combine to define a specific workflow within edoras one.

App models support the following settings:

Name: The name of the App
Primary language: The primary language to be used for the models in the App (i.e. the language used in base attribute values).
Secondary languages: Secondary languages that will be supported by the models in this App. When secondary languages are specified additional localization functionality will be enabled.
Description: Describes the purpose of the App. This is provided solely as information for modelers and does not have any runtime significance.
Group / User / Work Item Mappings: When an App is installed, the models may require references to other work objects outside of the App to function correctly, for example a specific user may have to be assigned to a particular role. Such references are specific will vary depending on the environment specific system, so the App model allows this information to be defined in a single location and then reused by different models.
Property Mappings: There may also be parameters that the modeler would like to be able to modify globally instead of hardwiring specific values into multiple models. This can be achieved using a property mapping. Properties defined in the App are accessible from all deployed definitions.

5. Case model

All case models support the following settings:

Name: The name of the model
Description: Describes the purpose of the model. This is provided solely as information for modelers and does not have any runtime significance.
Model type: Either Adaptive Case Model or CMMN Case Model as required.
Init form: A reference to the initialization form model. This form is used to set the initial state of the case when a new case is created based on this model.
Work form: A reference to the work form model. This form is used to view and / or update the state of the case after it has been created.
Candidate Groups: The initial groups with which a newly created case will be shared.
Allowed Actions: The actions that may be performed on the case after it has been created.

5.1. Adaptive case model

In addition to the shared case model settings, adaptive case models support the following settings:

Autostart Processes: References the models for processes that will be started automatically in the context of a new case.
Autostart Tasks: References models for tasks that will be added automatically in the context of a new case.
Autostart Documents: References models for documents that will be added automatically in the context of a new case.
Ad-hoc Processes: References the models for processes that can be started manually in the context of a new case. If no models are selected then all process types will be supported.
Ad-hoc Tasks: References models for tasks that will be added manually in the context of a new case. If no models are selected then all task types will be supported.
Ad-hoc Documents: References models for documents that will be added manually in the context of a new case. If no models are selected then all document types will be supported.

5.2. CMMN case model

No additional specific settings are provided by CMMN case models

The CMMN model can be designed in edoras vis by using the Design action in the case model. For information on creating CMMN case models please refer to the CMMN Documentation.

6. Task model

Task models support the following settings:

Name: The name of the model
Description: Describes the purpose of the model. This is provided solely as information for modelers and does not have any runtime significance.
Init form: A reference to the initialization form model. This form is used to set the initial state when a new task is created based on this model.
Work form: A reference to the work form model. This form is used to view and / or update the state of the task after it has been created.
Candidate Groups: The initial groups with which a newly created task will be shared.
Allowed Actions: The actions that may be performed on the task after it has been created.

7. Document model

A document model is used to define a new type of document and supports the following settings:

Skeleton document: An optional skeleton document. The skeleton document will be copied into each new document work item as it is created, so each document instance will have its own separate copy. If placeholders are defined then these will also be substituted when the document is copied. Once a document model has been created, the skeleton can be managed using the Upload skeleton and Download skeleton actions.
Name: The name of the model
Description: Describes the purpose of the model. This is provided solely as information for modelers and does not have any runtime significance.
Init form: A reference to the initialization form model. This form is used to set the initial state when a new document is created based on this model.
Work form: A reference to the work form model. This form is used to view and / or update the state of the document after it has been created.
Candidate Groups: The initial groups with which a newly created document will be shared.
Allowed Actions: The actions that may be performed on the document after it has been created.
Placeholders: A placeholder has a key (which can be referenced from the skeleton document) and an expression which will be evaluated when a new document is created. The placeholders are evaluated and replaced in a copy of the skeleton document when a new document work item is created, allowing documents to be filled out automatically with dynamic text.

7.1. 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.

7.2. 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:

7.3. 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.

7.4. 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.

More information is available about merge mails from the following links:

7.5. Microsoft Word Linq support

Microsoft Word documents support the Linq query language. The platform uses Aspose to provide the basic Linq functionality and we integrated our own data retrieval mechanism to support the already known backend expressions. Please read the mentioned links below to familiarize yourself with the Linq expressions and how they are interpreted.

The following snippet of a Word document show some examples of how to use Linq in combination with the work object structure and the backend expressions:

Single String value:

    <<[linq.value("#{name}")]>>

Conditions:

    <<if [linq.booleanValue("#{priority > 10}")]>>
        Condition: <<[linq.value("#{priority}")]>>
    <</if>>

Iterations:

    <<foreach [item in linq.foreach("#{itemsList}")]>>
        Item: <<[item]>>
    <</foreach>>

Nested iterations:

    <<foreach [item in linq.foreach("#{listInList}")]>>
        Item:
	    <<foreach [innerItem in linq.foreach(item)]>>
		    Inner item: <<[ innerItem]>>
        <</foreach>>
    <</foreach>>

Iterations with list of maps:

    <<foreach [item in linq.foreach("#{mapItems}")]>>
        Map Value 'a': <<[linq.value("#{a}", item)]>>
        Map Value 'b': <<[linq.value("#{b}", item)]>>
        Merged value: <<[linq.mergedValue("#{name.concat(' - ').concat(a)}", item)]>>
    <</foreach>>

In the above examples we use the linq key word (or context) to get the values and iterate over lists which are retrieved by a backend expression. This linq context is used to get the data from the backend expressions to be processed by Linq. In the following list you see all available methods on the linq context and what their purposes are:

Table 4. `linq` methods
Method	Expression context	Return value	Default return value	Purpose
`value(String expression)`	Document work object	`Object`	Empty `String`	Evaluates the expression and returns the resolved value.
`value(String expression, Map contextObject)`	Specified `contextObject`	`Object`	Empty `String`	Evaluates the expression based on the `contextObject` and returns the resolved value.
`mergedValue(String expression, Map contextObject)`	Document work object and specified `contextObject`	`Object`	Empty `String`	Evaluates the expression based on the document work object merged with the `contextObject` and returns the resolved value.
`stringValue(String expression)`	Document work object	`String`	Empty `String`	Evaluates the expression and returns the resolved value.
`stringValue(String expression, Map contextObject)`	Specified `contextObject`	`String`	Empty `String`	Evaluates the expression based on the `contextObject` and returns the resolved value.
`mergedStringValue(String expression, Map contextObject)`	Document work object and specified `contextObject`	`String`	Empty `String`	Evaluates the expression based on the document work object merged with the `contextObject` and returns the resolved value.
`longValue(String expression)`	Document work object	`long`	`-1L`	Evaluates the expression and returns the resolved value.
`longValue(String expression, Map contextObject)`	Specified `contextObject`	`long`	`-1L`	Evaluates the expression based on the `contextObject` and returns the resolved value.
`mergedLongValue(String expression, Map contextObject)`	Document work object and specified `contextObject`	`long`	`-1L`	Evaluates the expression based on the document work object merged with the `contextObject` and returns the resolved value.
`doubleValue(String expression)`	Document work object	`double`	`-1.0D`	Evaluates the expression and returns the resolved value.
`doubleValue(String expression, Map contextObject)`	Specified `contextObject`	`double`	`-1.0D`	Evaluates the expression based on the `contextObject` and returns the resolved value.
`mergedDoubleValue(String expression, Map contextObject)`	Document work object and specified `contextObject`	`double`	`-1.0D`	Evaluates the expression based on the document work object merged with the `contextObject` and returns the resolved value.
`booleanValue(String expression)`	Document work object	`boolean`	`false`	Evaluates the expression and returns the resolved value.
`booleanValue(String expression, Map contextObject)`	Specified `contextObject`	`boolean`	`false`	Evaluates the expression based on the `contextObject` and returns the resolved value.
`mergedBooleanValue(String expression, Map contextObject)`	Document work object and specified `contextObject`	`boolean`	`false`	Evaluates the expression based on the document work object merged with the `contextObject` and returns the resolved value.
`foreach(String expression)`	Document work object	`Iterable`	Empty list	Evaluates the expression and returns the resolved list.
`foreach(Object object)`	No context	`Iterable`	No default value	Checks if the specified `object` is a map and takes out the first element and assumes it is a list. If the `object` is a list it will return the list right away.

In the merged* methods the specified contextObject is preferred over the document work object. This means that when the document work object has a variable a and the contextObject map has an entry with key a, then the value of the contextObject will be used and not the variable value of the document work object.

You can also check the com.edorasware.cloud.core.service.document.word.LinqContext class to see the details of our implementation.

More information about Linq is available at the following links:

Aspose documentation about what we currently support: https://docs.aspose.com/display/wordsjava/LINQ+Reporting+Engine+Programmers+Guide
Official Microsoft Linq documentation: https://msdn.microsoft.com/en-us/library/bb397926.aspx

8. Form model

A form model defines a form that can be used by other workflow models to interact with the user.

Form models support the following settings:

Name: The name of the model
Description: Describes the purpose of the model. This is provided solely as information for modelers and does not have any runtime significance.

The form layout can be quickly checked in edoras one by hovering over the form model in the App’s model list, previewed within the form model using the Preview view or edited in the edoras vis modeler using the Design action. It is also possible to download the form definition using the Download action.

The following sections describes the elements available in the form palette of edoras one. Each modelling element and its corresponding attributes are described in detail below.

8.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.

8.1.1. 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 1. 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 2. 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 3. Form layout with empty slots

8.1.2. 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 4. Field layout

8.1.3. 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 5. 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 6. Field alignment with top label position

8.1.4. 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 cannot be used as they are used internally to save some work item information. The reserved frontend expressions 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.

8.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.

8.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.

8.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 a floating point 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.
	Used to input work object comments. Do not change default variable name. Variable name create binding for the comment handling. Comments can be only added during create, complete and save work object events.

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 a floating point 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.

Used to input work object comments.

Do not change default variable name. Variable name create binding for the comment handling. Comments can be only added during create, complete and save work object events.

8.4.1. 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.

8.4.2. 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.

8.4.3. 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.

8.4.4. 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.

8.4.5. 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.

8.4.6. 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.

8.4.7. 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.

8.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	Select options	Used to select one option from a list of options. The list of options is built at runtime by querying edoras one (datasource = Query) or any other rest service (datasource = Rest) or defined at design time (datasource = Static).
Multiple	Select options	Used to select one or more options from a list of options. The list of options is built at runtime by querying edoras one (datasource = Query) or any other rest service (datasource = Rest) or defined at design time (datasource = Static).

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

Select options

Used to select one option from a list of options.

The list of options is built at runtime by querying edoras one (datasource = Query) or any other rest service (datasource = Rest) or defined at design time (datasource = Static).

Multiple

Select options

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

The list of options is built at runtime by querying edoras one (datasource = Query) or any other rest service (datasource = Rest) or defined at design time (datasource = Static).

The Radio button group is recommended when there are few options while the Single Select is recommended when there are more options or there is not much space available in the form.

8.5.1. 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.

8.5.2. 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

8.5.3. Select attributes

Attribute name

Description

Common

See Common attributes to learn more about the common attributes.

Setting $options as default value will make that all the available options are set by default in the component. Setting $options[0] will select the first available option.

To select one specific option please use only the id (see Identity). Eg. defaultValue = GEAR-a65c4a12-20b4-45d8-bb09-2105be7f0d1f. To select more than one item by id please type the ids separated by commas. Eg. defaultValue = GEAR-1,GEAR-2.

Validation

The 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.

Placeholder

Used to set up the placeholder text. The component shows the placeholder text until the field is focused upon, then hides it.

Enable autocomplete

When checked the user will be allowed to write text in the component, this text is then used to filter the options to those that match the text.

Input minlength

The minimum number of characters the user needs to write inside the component before any option is shown. When it’s set to 0 the component dropdown appears immediately when the component gets the focus.

Storage

When it’s set to Id only the attribute defined in Identity will be persisted in the data model. When it’s set to Full the whole object will be saved as it’s returned from the rest service.

This attribute is not available when datasource is Static.

Datasource

Used to set up the source of the options.

Possible values are:

Rest ⇒ Data from any Rest service
Query ⇒ Data from edoras one
Static ⇒ Data defined on model time

Each option requires a different set of attributes.

8.5.4. Static Select specific attributes

Attribute name	Description
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

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.

8.5.5. Rest Select specific attributes

Attribute name

Description

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 can be used in the expression as {{$searchTerm}}. If it’s not set in the Query URL it will be added as a URL parameter.

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.

The URL is encoded automatically so it shouldn’t be encoded.

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

The lookup URL can use expressions but the only available attribute from the selected option is {{$item.id}}. The id attribute of the selected option must be set in Identity (see next point). If {{$item.id}} is not set in the lookupUrl, the id 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 Identity. So the Lookup URL and the Identity attribute have to play together.

The URL is encoded automatically so it shouldn’t be encoded.

Identity

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

So if the JSON option looks like

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

and Identity = code then GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac will be stored in the data model.

Please note that the Identity, the Query URL, and the Lookup URL attributes have to play together. The Identity 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.

I allows frontend expressions. The selected option is available as $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",
  "type": "TSK"
}

then a format of Group: {{$item.type}} - {{$item.title}} results in Group: TSK - 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

8.5.6. Query Select specific attributes

Attribute name	Description
Search 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

Attribute name

Description

Search 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

8.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 button which, providing the model id of a plan item which has manual activation or an user event listener, has the same functionality than an CMMN action. Note that the button is only displayed in a CMMN template and if the action is available.

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.