Skip to main content
Version: 1.20.1

Version 1.20.1

warning

Before you deploy the ITSM version 1.20.1, ensure that you have the 1.29.0 or later version of the platform installed, as well as the ESM version 2.0.0.

In this version, we have continued improving the automation of change enablement practices: we have added the ability to export a change work plan into a PDF file, expanded the change request form with the Announcement required checkbox, and updated a range of rules for change requests and their related tasks. We have also implemented notifications about changes in tasks for the users assigned to these tasks' parent records.

Apart from that, we have introduced fixes for the:

  • missing logic for the Assigned user field autocompletion when completing tickets in bulk,
  • incorrect linking of composite keys to monitoring messages under extreme load,
  • problems not transitioning from the Postponed state on the date and time of the Resumption of work,
  • incorrect mandatory field logic when canceling change requests by clicking Cancel on their form,
  • inactivity of the Save button in the New endpoint modal window when all the fields are filled in.

New functionality​

Export a change work plan to a PDF file​

It is now possible to export a change request's work plan to a PDF file. This ensures that users can access the information even when they do not have access to the system, for example, when working on the ground.

To enable this, we have added the Export to PDF button to the burger menu on the change request form. Clicking it generates a file that contains the change request fields pertaining to the work plan. The information is displayed only if the corresponding values are provided in the change request.

Read more in the documentation.

Improvements​

Announcement required checkbox and other updates to change requests​

We have expanded the change request form with the Announcement required checkbox. It allows the agents responsible for sending notifications about the changes, for example, about the planned availability of services for consumers, to track the records that necessitate publishing an announcement.

If the checkbox is selected, the system verifies whether there is a Published announcement related to the change request. If there is one, the Announcement published system checkbox gets automatically selected on the change request form.

In addition, we have updated a range of rules for change requests and their related tasks. The Preparation phase tasks can now have an earlier Planned start datetime than the change request itself. The rule for the correlation of dates also does not apply to canceled tasks. For implemented or partially implemented changes, the tasks in the Rollback phase now automatically get canceled if the tasks in other phases are completed or canceled.

We have also added notifications about starting the work on change tasks, as well as about the rejection of a change request template by an approver.

Read more in the documentation:

Task notifications​

The users assigned to service requests, change requests, incidents, and problems will now get notifications about the following changes in the related tasks:

  • state changes,
  • Work note addition,
  • change of the assigned user.

This will help users keep track of the progress in tasks and quickly react to the changes.

We have also added notifications for the users added to or removed from a task's Followers list.

Read more in the documentation:

Fixes​

DEF0022370: When mass completing the tickets that had an empty Assigned user field, it remained empty. In this version, we have added the processing of this scenario. The empty Assigned user field is now filled in with the user who performed the mass completion. The Assignment group also changes to this user's main group if this user is not part of the specified assignment group. Read more in the documentation:

DEF0021617: An influx of monitoring messages resulted in incorrect linking of composite keys to these messages: the keys displayed the data of other messages. This was caused by the Transform Map (sys_transform_map) returning the same composite key every time. In this version, we have fixed this behavior. Composite keys in messages now only include the applicable data.

DEF0021435: Problems did not transition from the Postponed state on the date and time of the Resumption of work. This occurred because the automatic state transition was not configured, and the display of fields under different Postponement causes was incorrect. In this version, we have added the transition from the Postponed state and corrected the display of fields. The Resumption of work field is now displayed only if the Postponement cause is set to Implementation postponed, while the External company and External tasks fields appear and become mandatory if the Postponement cause is External processing. If the Postponement cause changes, these fields are cleared. Read more in the documentation:

DEF0018951: To cancel a change request via the Cancel button on its form, users had to fill in the Work notes field, as well as the fields on the Planning tab. In this version, we have corrected this mandatory field logic. When canceling a request using the button, the request moves into the Completed state with the Not implemented (Canceled) closure code. Filling in the fields is not required. Read more in the documentation.

DEF0018394: When connecting a Telegram bot, it was impossible to create an endpoint. In the New endpoint modal window, the Save button remained inactive despite filling in all the fields. This occurred because this button's activity depended on the same variable as the Set button on the bot connection page. Thus, if the bot connection page had some empty steps, the button in the modal window was inactive. In this version, the Save button in the New endpoint modal window is always active.