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

Compare with Current View Page History

« Previous Version 13 Next »

IT components come and go. They are planned, purchased, operated and eventually taken out of service. Bingo: This is about the lifecycle management. This plays an important role in the IT documentation, since it can be used to track the state that 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 a column in the object lists in order to see the target condition of a documented object 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. If a new object is created, it receives in operation as its CMDB status, if not explicitly set to a different state..



Manage CMDB Status

The adding, changing or deleting of a CMDB status is done via Administration → CMDB settings → CMDB status. For each 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 made a subject of a lifecycle. A documentation artifact can be archived once it is not needed anymore. An artifact can also be marked as deleted, so a person being responsible for the IT documentation can irrevocably remove this artifact via Purge.

Deletion process

It may be worthwhile for bigger environments to establish the needed processes for the archiving and the deletion of documentation artifacts. At what point is something going to be archived? Who may clean up the IT documentation? These kind of questions need to be addressed by the team. The permission system of i-doit contains the required settings in order to assign the rights to archive or to purge 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 purged 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 the 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 can then be used. Because of this they should be removed on a regular basis. This can be done via Administration → Systemtools → Cache / Database → Remove unfinidshed objects. This can also be done automatically. More details for this can be found further below.
  • Template: An object can be used as a template for other objects.
  • Change template: An object can be used as a change template for mass changing.

The Purge function is used after marking a documentation artifact as Deleted if you wish to purge it. This however is not a state because all data (including the current state and any logbook entries) is lost doing this, so no traces of this object can be found anymore. This function should be used with much care.

Archive Objects, Mark them as Deleted or Purge them

The state of an object is visible in the General category. If you wish to archive an object, mark it as deleted or purge it, then you will be able to do so 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 is only possible to change to the next state. If an object in the Normal state, then it will only be possible to change it to the Archived state. It is then only possible to delete it by using the list which is filtered to archived objects in the upper right corner. Using Recycle changes the object to the previous state.

There is no further query when purging except if relations to other objects exist.

Archive Category Entries, Mark them as Deleted or Purge them

A similar functionality to the 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 purge a documentation artifact it first has to be archived and marked as deleted. To shorten 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 purged regardless of its 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.

Remove 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 can not be edited. However, archived objects or objects marked as deleted are also not desired in a lot of cases. The same applies to category entries. Because of that it is possible to purge these documentation artifacts. This can be done in two ways: manually or automatically.

Manual Deletion

These 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 buttons a notification will be displayed, showing the amount of objects/category entries which you are about to delete. After the deletion it shows statistics of the amount of objects / category entries that have been deleted.

Automated Deletion

The controller also offers a possibility to delete undesired objects. The corresponding handler is cleanup_objects. The -t parameter determines the group of objects that are deleted based on their state:

  • -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 executing the controller on a regular basis via cron job. An example with other important cron jobs can be found in the article regarding 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 purged, the logbook entries associated to them are permanently deleted.