change the object status

When you create a new object you have to assign it a lifecycle to define its behavior according to the application environment. A lifecycle may have one or more stages or the same concept a stage defines a portion of an object’s lifecycle. Depending on which stage an object is in, a user, team, or assignment may or may not have access to the object including the its movement into another stage.
After the creation, the object usually assumes the first stage in the lifecycle sequence and maintains this status until a user, with proper access rights, changes its status. The new status depends on the lifecycle sequence: if there is only a possible choice the next stage is reached with a simple progress operation, otherwise, when there are more branches out-coming from the current stage, the user has to select one of them before go forward to the relative stage. In some cases the user can also decide to go back to the previous stage through the path followed to reach the current: in this case we speak about a regress operation.

Progress / Regress operations

The progress operation allows to move an object from its current stage into the next stage when all requirements are met. If the lifecycle specifies only one stage or if the current stage is a terminal node in the sequence (there isn't any path out-coming from it), an object cannot be promoted. However, if a lifecycle has several states, progression is the means of transferring an object from one stage into the next. The order in which stages are defined is the order in which an object will move when it is promoted.
Users can change object status by the "Domain Object Manipulation" client. Simply search/select the object and push the "Lifecycle" button.

In the "Lifecycle" window you can see the lifecycle stage sequence for the selected object with current stage highlighted. The Progress button lets you to move the current status to the next. If there is a path represented with the green color out-coming from the current stage means that requirements are met and the operation is allowed. Next status will be the stage reached following the given path.

The progres OOQL command is:

If an object reaches a stage and you determine that it is not ready for that status, you would want to send the object back for more work.
The Regress button (or the regress OOQL command) lets you to move back the current status to the previous (if there is).

If the lifecycle has only one stage or is in the first state, an object cannot be regressed. However, if a lifecycle has several stages, regression is the means of transferring an object backward from one stage into the previous stage. To change the object status, a user must have the progress/regress privilege activated in the current lifecycle stage of the object.

It is also possible to jump to a specific stage with the following OOQL command:

Multiple branches and Validations

When a stage is defined within a lifecycle, a validation can be required for the object to let it to go forward to the next stage. In OBEROn the validations have the double aim of selecting the out-coming path and consequently the next stage (stagefork) when there are more possible options and introducing some conditions for the object's status progression.
If 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 the approval. If he tries to progress the object when defined validations are not satisfied for any possible path, the system returns an error and blocks the operation.

However, the validation approval operation does not necessarily mean that the object will be progressed to the next stage. It only means that one of the requirements for progression was addressed. Depending on the stage definition, more than one validation may be required for a specific path. Only when all validations for a given path are validated the path becomes open (green status) and a progress operation can be performed (automatically if the autoprogress option is activated) along this path. To manage validations for a specific path you can double click on the path from the lifecycle graph and select the validation to operate with.

In the list of validations associated to the selected path you can choose a validation and operate on it with the following commands:
- validate: accepts the requirement represented by this validation
- refuse: rejects the specific requirement; this means that object cannot be promoted toward the path's related destination stage.
- ignore: bypasses the requirement; in this case, you are not providing a validation or refuse for the requirement. Instead, you are specifying that this validation can be ignored for this object.
[Note: In a lifecycle definition, stages are created to serve the majority of objects of a particular class. This means that you may have some objects that do not need to adhere to all of the constraints of the lifecycle.]

The operation is allowed only if you have the privilege activated in the current lifecycle stage of the object on the base of your assignments or the teams you belong.

You could include a comment so that other users can understand the reason of your choice or to provide additional information regarding the validation.

The equivalent OOQL command is:

An object is promoted to the next stage automatically when all requirements are met if the stage was defined with the autoprogress clause. On the other case the status remains the same even if all requirements are met for a specific path, until the user performs a progress operation.

Note: you can progress the object status if and only if a single path is opened; if more paths are available (green status) at the same time there will be an ambiguity for the system and the operation will be blocked.
This situation should happen when the autoprogress options is inactive and you validate different paths or when for some reason the system cannot (auto)progress the status to the next stage because some triggers block the event.
In case of regression, all validation conditions for the current stage are kept, so if the object is successively promoted again to this stage you can find the validations already signed. To avoid this situation, you can enable the autoreset flag for the stage to force the validation reset during the regress action.