You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »


IT-components come ang go. They are planned, purchased, operated and eventually taken out of service. Bingo: This is about the life cycle management. This plays an important role in the IT-documentation, as it can be used to track the status a component has or should have. It should also be possible to archive and delete the IT-documentation itself.

Lifecycle of IT-components

The lifecycle of an IT-component is documented in the CMDB-status. The following CMD-status' are available with a fresh i-doit installation:

  • planned
  • ordered
  • delivered
  • assembled
  • tested
  • in operation
  • defect
  • inoperative
  • under repair
  • delivered from repair
  • stored
  • scrapped

The CMDB-status can be displayed as column in the object lists in order to see the target condition as fast as possible.


By representing the lifecycle it is possible to use i-doit for planning. Whether there is an imminent big update or relocation - the IT-documentation is always present and offers valid statements.

Set CMDB-status per object

To represent the complete lifecycle of an object, the CMDB-status attribute in the General category is used per object. Is a new object created, then it receives in operation as CMDB-status, if not explicitly set to a different status..



Administrate CMDB-status

The adding, changing or deleting of a CMDB-status is done via Administration → CMDB settings → CMDB-status. Per CMDB-status the following information is needed:

  • Unique name/language constant (for translation)
  • Unique constant (helpful for using the API for example)
  • Color (is used in object lists, the General category, in the CMDB-Explorer and many other places)

Lifecycle of the IT-documentation

Apart from the objects that are to be documented, the documentation itself can also be subordinated to a lifecycle. A documentation artifact can be archived once it is not needed anymore just as an artifact can be marked as deleted so a person being responsible for the IT-documentation irrevocably deletes this artifact via Purge.

Deletion process

It may be worthwile for bigger environments to establish the needed processes for the archiving and deletion of documentation artifacts. When is something going to be archived? Who may clean up the IT-documentation? This kind of questions need to be addressed in the team. The permission system of i-doit contains the required settings in order to just assign the rights to archive or to irrevocably delete something to specific users.


Almost all documentation artifacts (objects, category entries, values in Dialog+-fields etc.) receive a state.

  • Normal: When working normally (create, edit) each artifact receives this state and can be used anywhere.
  • Archived: The artifact is hidden from the IT-documentation. Further use, e.g. linking is not possible anymore.
  • Deleted: The artifact is supposed to be deleted irrevocably (Purge) but still exists completely with all relations in the IT-documentation. Apart from this that state is similar to Archived.

The cycle proposes for each documentation artifact to have Normal state. Later on they will be Archived and then Deleted. A restoration to the previous state is possible at any time.

Special cases exist concerning objects in addition to these three states.

  • Unfinished: This state is assigned to a new object that has been created but not saved. This happens for example if an object is newly created, the Save button however has not been used. These objects can only be found via a report and then be used. Because of this they should be deleted on a regular basis. This can be done via Administration → Systemtools → Cache / Database → Remove unfinidshed objects. This can also be done automatically as an alternative. More details for this can be found further below.
  • Template: An object can be used as a template for ruther objects.
  • Change template: An object can be used as a change template for mass changing.

Is a documentation artifact to be deleted irrevocably, then the Purge function follows the marking as Deleted. This however is not a state because all data (including the current state and any logbook entries) are lost doing this, so no traces of this object can be found anymore. This function should be used carefully.

Archive objects, mark them as deleted or delete them irrevocably (Purge)

The state of an object is visible in the General category. Is an object to be archived, marked as deleted or deleted irrevocably, then this is done via the object lists. For this the checkboxes of the corresponding objects are marked and one of the buttons Archive, Delete or Purge are used.

It's only possible to change to the next state. Is an object in the Normal state, then it can only be changed to the Archived state. It's only possible to delete then by using the list filtered to archived objects in the upper right corner. Using Recycle changes the object to the previous state.

There is no further query when deleting irrevocably (Purge) except if relations to other objects exist.

Archive category entries, mark them as deleted or delete them irrevocably (Purge)

A similar functionality as for objects exists for some list categories ("Multi-value"). Here category entries can be archived, marked as deleted and purged.

Simplified deletion (Quickpurge)

In order to delete a documentation artifact irrevocably it has to be archived and marked as deleted first. To abbreviate this cycle, it is possible to activate the Quickpurge button. This is done at Administration → System settings → System parameters → Activate Quickpurge button. This way an object or category entry can be deleted irrevocably regardless of the state.

Listing of all objects that are archived or marked as deleted

A report which can be configured via the Query Builder can be used to get a list of all objects that are archived or marked as deleted.

Delete objects or category entries that are unfinished/archived/marked as deleted collectively (Purge)

Unfinished objects are unwanted in almost all cases since they are not visible and so cannot be edited. However, archived objects or objects marked as deleted are not wanted in a lot of cases. The same applies to category entries. Because of that it is possible to delete these documentation artifacts permanently (Purge). This can be done in two ways: manual or automated deletion.

Manual deletion

Tehse artifacts can be deleted via the web GUI. The respective function is located at Administration → Systemtools → Cache / Database → Objects or Categories. After using one of the offered buttons a notification is displayed, showing the amount of objects/category entries which are about to be deleted. After the deletion it shows statistis of how many objects / category entries have been deleted.

Automated deletion

The controller also offers a possibility to delete unwanted objects at least. The corresponding handler is cleanup_objects. Which objects are to be changed to what state is stated in the parameter -t:

  • -t 1: delete unfinished objects
  • -t 3: delete archived objects
  • -t 4: delete objects that are marked as deleted

Example for the deletion of unfinished objects:

./controller -u admin -p admin -i 1 -m cleanup_objects -t 1

The automation consists of perfoming the controller on a regular basis via Cronjob. An example with other important Cronjobs can be found in the article concerning the controller.

Change of states in the logbook

Changes of states are summed up completely by the logbook. Only when an object/category entry is deleted irrevocably (Purge) the logbook entries associated to them are permanently deleted.