The CMDB CI entity is used to manage all CIs in Deepser (devices, softwares, contracts, etc.).
CIs can be created by Administrators, Agents and Key Users.
End Users cannot access this resource via API.
Endpoints
http://deepserhost/api/rest/cmdb/ci/[id]http://deepserhost/api/rest/cmdb/cisRoles
Here we list all the permissions by user role regarding the API:
| Admininistrator | Agent | Key User | User | |
|---|---|---|---|---|
| Actions Allowed | RETRIEVE CREATE UPDATE DELETE | RETRIEVE CREATE UPDATE DELETE | RETRIEVE CREATE UPDATE DELETE |
Fields
Here we list all the fields of the entity to describe their meainings in Deepser:
| Field | Meaning |
|---|---|
| name | The name of the CI. Usually a brief description. |
| type_id | The type of the CI. It is a very important value to manage the organization of the CMDB. |
| class_id | The Class the CI belongs to. |
| subtype_id | The Subtype of the CI. It is a very important value to manage the organization of the CMDB. |
| category1 | The category (1st Level) of the CI. It can be used according to the category of the Service module, in order to link Operations and CIs. |
| category2 | The category (2nd Level) of the CI. It can be used according to the category of the Service module, in order to link Operations and CIs. |
| category3 | The category (3rd Level) of the CI. It can be used according to the category of the Service module, in order to link Operations and CIs. |
| description | Large description of the CI. |
| status | The status of the CI. It is an important value to manage the lifecycle of the element. |
| priority_id | Priority of the CI from the operator perspective. |
| urgency_id | Urgency of the CI from the requester user perspective. |
| business_impact_id | Business Impact of the CI from the organization perspective. If a CI is not available, the business impact represents the enormity of the situation and can be in terms of people, finances, systems, etc. For example, it can describe: the number of people affected by the CI outage or the potencial financial losses, or the number of other systems affected. |
| serial_number | The serial number of the CI. |
| notes | Large Notes field. |
| front_image | The main image of the CI. |
| back_image | The back image of the CI. For example, if the CI is a rack, we can take a photo of the back side in order to see the connections or the cables. |
| assigned_company_id | Company that has taken in charge the CI. It is typically a Service Provider Company that has to monitor the CI. This field is very important to give the right visibility on the CIs. If a user has company restricted visibility, he cannot see CIs of other companies. Notice that a user with restricted company visibility can always see both CIs with its company in the Assigned Company OR Owner Company field. |
| assigned_group_id | User Group that has taken in charge the CI. It is typically a Service Provider Group of agents/key users that has to monitor the CI. This field can be left blank if there is no specific group assigned to the CI, otherwise it can be used to restrict permissions to groups. |
| assigned_username | The users who has taken in charge the CI. It is typically a Service Provider agent/key user that has to monitor the CI. This field can be left blank if there is no specific user assigned to the CI, otherwise it can be used to restrict permissions to single users. |
| owner_company_id | Company that is the owner of the CI. It is typically a Customer Company that uses the CI. This field is very important to give the right visibility on the CIs. If a user has company restricted visibility, he cannot see CIs of other companies. Notice that a user with restricted company visibility can always see both CIs with its company in the Assigned Company OR Owner Company field. |
| owner_group_id | User Group that owns the CI. It is typically a Customer or User Group of end users that can open requests on the CI. This field can be left blank if there is no specific group that owns the CI, otherwise it can be used to restrict permissions to groups (eg: when a user submits a request it could link only CIs owned by his user group). |
| owner_username | User that owns the CI. It is typically a Customer or end user who can open requests on the CI. This field can be left blank if there is no specific user that owns the CI, otherwise it can be used to restrict permissions to users (eg: when a user submits a request it could link only CIs owned by himself). |
| version | The version of the CI. Deepser stores in its DataBase every version of the CIs. We can always know the changes, the user that made a change and the date. |
| created_at | Creation date of the record. |
| updated_at | Date of the last update on the system. |
| updated_by | The user that has lat updated the CI. |
