Version 1.14.0
In this version we have added an option to use email as a monitoring system source, improved the service request classification logic, updated the logic for linking parent and child incidents, and made improvements and fixes to the change request logic.
New features
Processing email messages from monitoring systems
We have added the functionality of creating events from email messages which substantially widens the area of application of the monitoring events processing engines.
For this purpose, we have added a new monitoring source type – Emails, that allows to receive messages from external monitoring systems that do not support sending JSON data. For configuring the email processing, we have added an additional step to the monitoring source creation wizard that allows to configure the parsing of email messages into JSON data for subsequent processing.
Read more on the monitoring source configuration in the documentation.
Classification of service requests by service
We have added an option to classify service requests by service, which is especially convenient if the Service Catalog has a complex hierarchy of parent and child services.
For this purpose, we have added a new Master Service field to the service request form. If it is filled in, the Service field only has the services with the same Master Service available for selection. If Master Service is empty, all services are available.
We have also added a new system property that hides the Master Service field from the service request form.
Read more on creating service requests in the documentation.
Improvements
Parent-child incident relationship logic improvements
We have improved the logic of linking parent incidents to child incidents for the mass processing of incidents from the same event to be more convenient.
For this purpose, we have made the following changes:
-
You can now only add child incidents to infrastructure incidents.
-
You can now only add a child incident to an incident that has no parent incident.
-
When changing the state of a parent incident, the states of its child incidents automatically change to the same state.
-
When a parent incident enters the Completed state and the record is saved, the values of the Closure Information section fields are copied to the corresponding fields of the child incidents.
-
The following fields are also synchronized:
- Impact
- Urgency
- Priority
- Assignment group
- Assigned user
We have also added a new system property itsm.itsm_incident.map_assigned_group_and_user_to_children, that allows to disable the synchronization of the Assigned user and Assignment group fields (by default, the synchronization is enabled).
For a more convenitent monitoring of relationships between the incidents, we have added to their forms a new Child incident count field that is automatically filled in when child incidents are added, as well as a new Child Incidents related list.
Read more on creating relationships between incidents in the documentation.
Verification of planned dates for change requests
We have added validation of the Planned Start Datetime and Planned End Datetime fields of the change request form. The system now verifies whether the timeframe matches that of the change tasks related to the change request. If the timeframe of the change tasks falls outside of the dates specified on the request form, then:
- A warning is displayed below the Planned Start Datetime field and specifies the Change task with the earliest start date.
- A warning is displayed below the Planned End Datetime field and specifies the Change task with the latest start date.
The new feature allows the change managers to control the work on change request implementation more efficiently.
Read more on change schedules in the documentation.
Fixes
DEF0018974: We have added validation of the Planned Start Datetime and Planned End Datetime fields values on the Change Tasks form. Now you can only specify an end date that is later than the start date.