Workflows
Heads up! These docs are for Portofino 3, which is a legacy product. Check out Portofino 4!
Copyright 2008-2012 ManyDesigns srl. All rights reserved.
At the upstairs level, the modeler defines defines what steps a workflow is made of, the order in which the steps must be executed, the type of users that are invloved in each step.
At the downstairs level, the users can use the workflow to act on the data in a well organized and sequenced way.
The logical model behind workflows is the finite-state-machine (FSM) model. So you can think of it as a directed graph where the states are the nodes and the transitions are the edges.
A state describes the current condition of an object, i.e., to which step the workflow has progressed so far. On the other hand, a transition represents a change of state - the operation that users perform to progress with work.
For many aspects, a workflow attribute behaves like all other attribute types: it belongs to a class, it is implemented as a column in the database, it can be displayed in name/summary/details, and normal attribute permissions are applied to it.
But a workflow attribute has also some unique features, most notably that its state is updated using trasition buttons, rather than with an update operation.
The values the attribute can take are given by the workflow states (see below). If you do not mark the attribute as required, then the NULL value is also allowed. The NULL value is also called the undefined state.
When you create a new object, its workflow attribute takes a default value from its initial state field.
A workflow state has the following fields:
Contents
Purpose
Workflows are useful to coordinate the work of many users in a structured way. We often talk about workflows in connection to business processes, procedures and information lifecycles.At the upstairs level, the modeler defines defines what steps a workflow is made of, the order in which the steps must be executed, the type of users that are invloved in each step.
At the downstairs level, the users can use the workflow to act on the data in a well organized and sequenced way.
The logical model behind workflows is the finite-state-machine (FSM) model. So you can think of it as a directed graph where the states are the nodes and the transitions are the edges.
A state describes the current condition of an object, i.e., to which step the workflow has progressed so far. On the other hand, a transition represents a change of state - the operation that users perform to progress with work.
Workflow attributes
Before we deal with states and transition, we must first define a workflow attribute. Its purpose is to provide the storage for an object's current state. A class can have at most one workflow attribute.For many aspects, a workflow attribute behaves like all other attribute types: it belongs to a class, it is implemented as a column in the database, it can be displayed in name/summary/details, and normal attribute permissions are applied to it.
But a workflow attribute has also some unique features, most notably that its state is updated using trasition buttons, rather than with an update operation.
The values the attribute can take are given by the workflow states (see below). If you do not mark the attribute as required, then the NULL value is also allowed. The NULL value is also called the undefined state.
When you create a new object, its workflow attribute takes a default value from its initial state field.
States
Navigate to a workflow attribute. Locate the States section in the lower part of the page. This section displays the available states for the workflow, if there are any, and offers a link called Add a workflow state.A workflow state has the following fields:
- Workflow: a relationship to the workflow attribute
- Name: the name of the state.
Transitions
Navigate to a workflow state. In the lower part of the page you can see two types of relationships:- 'This state -> transition -> other state' shows the transitions from this state to other states;
- 'Other state -> transition -> this state' shows the transitions from other states to this state.
To create a new transition click on Add workflow transition and fill in the following fields:
- From state: the state this transitions originates from.
- To state: the state this transition ends in.
- Name: calculated automatically. Do no enter a value.
- Action: the name of the action, used as the name of the button to trigger the transition.
The initial state
The initial state is the default workflow state for newly created objects.The correct order to define it is as follows:
- create the workflow attribute without specifying the initial state;
- create the workflow's states;
- edit the workflow attribute to set the initial state to one of the states.
Permissions
A class with a workflow handles permissions in a different way. The basic principles discussed in thePermissions chapter are still valid, but an extra dimension - the workflow state - is added to the permission matrix.Notice the columns: there are a number of larger columns ("undefined state", "state 1", "state 2" in the example) corresponding to the various states. Within those columns there are a number of smaller columns ("A1", "A2", "A3" in the example) corresponding to the actors on the class: the triplet of actors is repeated for each state.
According to this improved permission matrix, the permissions (for operations, attributes, and transitions) can be specified per actor, per state, with maximum flexibility.
Permissions on transitions
In the permission matrix' rows, the third section contains the permissions on transitions. Unlike the other sections, the columns have different content. The column for a certain workflow state contains only transitions that originate from that state.Previous: Permissions
Next: Calculated attributes