The status system allows the user to customize the statuses of objects and to define relations between them himself, thus implementing very basic business logic in the application. For example, if the user customizes new statuses for the Order object, he may wish to define that a certain order cannot have a status Completed if it is currently Cancelled.

Statuses are organized in groups. The functionality of a group provides a way of defining that at any given time, a single record can only obtain a single status from this group. More than one group of statuses can be defined for a single object, thus allowing it to have more than one status. For example, an order can have a status Completed from a production point of view, and yet from a financial point of view to still remain Unpaid while the payment is still pending. This enables the user to monitor various processes within the application.

OBJECTS
Statuses are kept at several business objects:

• AOStatusGroup – defines groups
• AOStatus – the main object of statuses
• AOStatusAdditionalTask – defines the relation between a status and the AdditionalTask object
• AdditionalTask – this is a list of additional tasks, which may be conducted when a status is changed. They are application specific.
• AOStatusApplicationObjectUse – shows the objects that use the statuses of other. For example a single object can have a 1:1 relation to the object, which has a status. Therefore we can allow the user to change the status of this object.
• AOStatusCustomCheck – this table keeps information about the additional validation checks registered by the objects in the system. These checks are made at the change of a status, but are logically dependant so they cannot be de described in parameters. The developer creates a method with a certain signature in its class and registers it in the table. The method is called in when the respective status is changed, it can forbid this change and bring up an error notification.
• AOStatusCustomSchedule – shows the scheduled change in statuses
• AOStatusDependency – shows the dependency on other statuses
• AOStatusRelatedObjectDependency – shows the dependency on other statuses
• AOStatusUserDelay – shows a delayed change by user
• AOStatusUsersGroupAccessRight – shows the rights of groups of users to change a status
• AOStatusUsersGroupEditingRight – shows the rights of groups of users to edit a record in a certain status.

DEFINITION OF STATUS
A status is defined by its code, name, group and relation to an object. Additional features are also defined - if this is a default status, if it is visible and if overwriting is allowed. One can also indicate if the status requires a user interface when changed or not.

LIMITATIONS AND CHECKS
For a single status, limitations originating from other statuses or statuses of related objects can be defined (e.g. an order cannot be considered Paid, unless all its payments have been provided). The following limitations may apply for each limitation originating from another status (or from a related object):

• It has happened
• It has not happened
• It is current
• It is not current

Additional checks can be added and defined during the system design phase, and declared specifically for an object.

ACCESS RIGHTS
There are two types of access rights both of which are defined at user group level:

• Status change right – indicates which group of users can change a certain status
• The right to edit a record in a status – indicates which group of users can edit a record in a certain status (e.g. only the technical experts are allowed to edit an order which is still in „Production” status). This status can be additionally limited by declaring dependencies on groups that the user who changed the status belongs to:
  • Always
  • Only if a user from the same group has changed it
  • Unless a user from the same group has changed it
  • If user belonging to a group in a list has changed it
  • Unless a user belonging to a group in a list has changed it

PERSONAL STATUSES
Statuses can be set personally for individuals. This means that when a status is changed the user who should be “notified” of the record must be declared. From then on, only this user will be allowed to edit it.

DELAYED STATUS CHANGE
This type of change delays the status for a given period of time and is set for individual users.

SCHEDULED STATUS CHANGE
It is possible to indicate that upon the change of a status another status should follow after a certain period elapses. For example, if the contact details of a client are to be confirmed each 2 months, a status can be scheduled „For Confirmation”, which will change 2 months after the status „Confirmed” has occurred.

CHANGE HISTORY
When defining a status to an object, Elements automatically creates a related object „Status History”, which is then recorded in a separate table and the information is saved about which user on which date changed which status from which group.

TECHNICAL DETAILS
When adding a status to an object for the first time, the AOStatus extension is registered to this object. It adds the columns for each group in the list as well as information about each group of statuses to the form– which is current, when it was replaced and which user has changed it. All visible statuses are added as actions to the object. The StatusHistory object is also created and it becomes non-context related to the object. In addition, the AOStatus object is registered for the AddComplete event of the object. When this event occurs the default status is assigned.

Prior to each status change the rights of the currently logged-in user are analyzed. Then a check is made to see if the object does not have any additional validations established and afterwards the fact that all checks have been completed is confirmed. If the status requires no user interface and if all the checks return valid, the status will be changed. In all other cases the user will see a window with the results from the verification checks, when they are considered to be valid. There is also an option to add a note, which is then recorded in the StatusHistory. When a status is changed for more than one record simultaneously, the validity checks are executed for each record separately.

When the form is shown, there is the option to provide a personalized interface from the object, which in all cases will inherit the form of the StatusHistory for change. In this way, the object can collect additional information when a status is modified.

When a status is changed successfully, the StatusChange event occurs, which can be monitored by all objects of the application.