how to control the object instance behaviour with a lifecycle

Business objects may have methods, rules, states as ways to describe the actions that can be performed with them. You cannot create an object instance in OBEROn without specify what is its behaviour inside the application environment. The object behaviour depends in part from the object type (or class) but mainly from the lifecycle associated to it. A lifecycle controls a business object: it specifies the rules that govern user access, validations, state transitions, revision rules, type of attachments, documents and so on. If you want to know what a user can do with a business object, you should look at the object’s lifecycle.

In details, a lifecycle includes all the following information:
• The object classes that may be subjected to it
• The types of documents (filetypes) that are allowed for objects associated with this lifecycle
and the default filetype automatically used
• The filespace where these files are stored into
• The revision rule that defines the labels in the revision sequence
... and some options :

The revision rule is an expression composed of positional digits (symbols) and separator characters.

The first revision is obtained by replacing every positional symbols with the first item in the corresponding sequences. The next revisions are computed by incrementing the most right symbol; when the digit sequence reaches the last element the rest is propagated to the other digits on the left, as in a usual positional number system.
For example the sequence generated from the rule R/2 will be:

I/0  I/1  I/2  II/0  II/1  II/2  III/0  III/1  III/2  IV/0  IV/1  IV/2 .......  IX/0  IX/1  IX/2  X/0  X/1  X/2

When you add a class under the lifecycle control, all derived classes in the class-hierarchy automatically will be subjected to it and it is not necessary to add all of them.

Moreover a lifecycle consists of a series of linked stages, each of which represents a state in the life of the governed objects and includes the following information:
• Who will have access to the object when it is in this stage
• What actions will be registered into the object history
• If the object can be revised (revisionable condition)
• The conditions required for changing state

A lifecycle may have one or more stages. This number depends from the type of objects it governs. For example, you might have a lifecycle for a static object that represents a company: you can update its information data like the name, the address, the telephone number, but it never changes its state. In this situation, you might have only one stage where access to modify this information is well defined.
To add a new stage simply click with the mouse right-button inside the drawing area; this stage will be appended to the end of the sequence. Otherwise, if you want to insert a new stage before or after another just select the reference stage and click over it. As soon as you add a new stage this takes a progressive name (Stage_1, Stage_2 ...); with a mouse double click over it, you can edit the stage properties included the stage name and description.

The access level for each stage is characterized by different conditions. The lifecycle allows the user access for a specific action on a object in the current stage if the access for the action is permitted:

• to the community or
• to the holder and the user is the object holder or
• directly to the user or to a user category (team or assignment) to which the user belongs

The user’s definition takes precedence over accesses granted in the lifecycle: if an access is denied in the user mask, the user will not have access to the specified action, even if the lifecycle assigns the access.
(*) However, a person can be “granted” access to an object instance even if the action is denied in the user definition. This possibility is called "delegation".
Users - who have the "delegate" access privilege for an object instance in the current stage - can delegate any or all the access privileges they have for an object to one or more user.

In particular the access precedence is computed as follow:
- if the user is a superuser, then the access is automatically granted
- if the user's general specification don't allow the action, the access is denied (see above *)
otherwise the access is allowed if the action is selected for:
- the community [refers to every user defined in the OBEROn database]
- the holder [refers to the user who is the current (main/alternative) holder of the object instance. The user who created an object it is identified as its holder and keeps this role unless this qualify is transferred to someone else]
- the user directly
- a team to which the user directly or indirectly (due to the team hierarchy) belong
- an assignment directly associated to the user or inherited from a team

Finally, if the user has no access for the given action on the basis of object's lifecycle, then he may have some delegations assigned by one or more delegator users to perform the action on the specified object. In this case, the system execute (recursively) the same checks for the delegators and if one of them results enabled, the action privilege is transferred also to the user that we are taking into consideration.

As said before you can also establish which actions performed on the governed object in a given stage are logged into the object history. If you set in the "History Trace" tab a specific flag, everytime a user performs the relative action a new record containing the action description, the event time and the user name, will be added in the history. The are two level of history settings: at the lifecycle level and at the single stage level; in the first case, the selected flags are valid for all stages and you cannot override the behaviour in the stage mask (selected flags fro the lifecycle are disabled in the history trace panel for stages).

The object status evolves respecting the stage sequence described by the lifecycle.
If this sequence is linear you know every time what is the next stage respect to the current stage. However, in most cases the stage diagram may be more complex; for example you can take into account the possibility to jump to other stages out of the main sequence.
When more branches take origin from a stage, you have to select the next stage during the progress operation. In OBEROn, "validations" are a way to control the change of an object’s stage. A validation definition is necessary every time you have more than one path from a given stage: each path will have at least one validation.
Validations can be associated with user, team or assignment. When a validation is required for a path, a user must validate the object in order for the object to move on to the next stage along that path. If that user does not validate it, the object remains in the current stage until the user does validate or until someone with higher authority provides approval.

A validation is characterized by the following parameters:
- the identificative name
- the destination stage (or stagefork)
- the access privileges to define which category of users can validate, refuse or ignore it

Sometimes a change in stage is controlled by one or more users when different people are involved in deciding whether the object is ready for the next state.
In this case more than one validation can be associated with the transition of an object and when all the validations for a given path (stagefork) are satisfied [validated or ignored] the object can be promoted. If the "autoprogress" option is activated for the current stage, the transition is automatically performed as soon as the last validation for the destination stage is satisfied.
When validation is refused, promotion to the next state is prevented from taking place.
It a user demote the object status to the previous stage, the validation conditions for the current stage are all kept; you can check the "autoreset" flag on the Properties panel to enable the validation signature reset on object status regression.

An equivalent lifecycle creation OOQL command might be: