Перейти к основному содержимому
Версия: 1.15.0

Версия 1.14.0

В новой версии мы добавили возможность использовать электронную почту в качестве источника для системы мониторинга, улучшили логику классификации запросов на обслуживание, доработали логику связывания дочерних и родительских инцидентов, а также внесли улучшения и исправления в логику работы с запросами на изменение.

Новая функциональность​

Обработка почтовых сообщений от систем мониторинга​

Дополнили модуль управления событиями мониторинга функциональностью создания событий из почтовых сообщений, что существенно расширяет сферу возможного применения механизма обработки событий мониторинга.

Для этого мы добавили новый тип источника мониторинга – Письма, который позволяет получать сообщения от систем мониторинга, не поддерживающих отправку JSON. Чтобы использовать письма как источник мониторинга, настройте парсинг почтовых сообщений и подготовку на их основе данных в формате JSON для дальнейшей обработки системой в дополнительном шаге мастера создания нового источника мониторинга.

Подробнее о настройке источников мониторинга читайте в документации.

Смотрите видео с обзором новой функциональности.

Чтобы узнать больше о модуле Мониторинг и управление событиями, смотрите обзорное видео.

Классификация запроса на обслуживание по услуге​

В этой версии появилась возможность классификации запроса на обслуживание по услуге, что особенно удобно когда в Каталоге услуг присутствует сложная иерархия родительских и дочерних услуг.

Для этого мы добавили на форму запроса на обслуживание новое поле Основная услуга. Если оно заполнено, то в поле Услуга для выбора будут доступны только те услуги, у которых основная услуга совпадает с указанным значением. Если поле Основная услуга не заполнено, то в поле Услуга для выбора доступны все значения из каталога.

Вы можете скрыть поле Основная услуга с формы при помощи нового системного свойства.

Подробнее о запросах на обслуживание читайте в документации.

Смотрите видео с обзором новой функциональности.

Улучшения​

Доработки связи родительских инцидентов с дочерними​

Мы улучшили логику связывания родительских инцидентов с дочерними для более удобной массовой обработки записей инцидентов по одному событию.

Для этого мы внесли следующие изменения:

  • Добавлять дочерние инциденты теперь можно только к инфраструктурным инцидентам.

  • Дочерний инцидент можно привязать к другому инциденту, только если последний не является дочерним.

  • При смене статуса родительского инцидента статус дочерних инцидентов автоматически меняется на тот же статус, что и у родительского.

  • При переводе родительского инцидента в статус Завершено и сохранении записи содержимое вкладки Информация о закрытии копируется в соответствующие поля дочерних инцидентов.

  • Также синхронизируются поля:

    • Влияние
    • Срочность
    • Приоритет
    • Назначено на группу
    • Кому назначено

    Кроме того, мы добавили системное свойство itsm.itsm_incident.map_assigned_group_and_user_to_children, которое позволяет отключить синхронизацию полей Кому назначено и Назначено на группу (по умолчанию синхронизация включена).

Для более удобного отслеживания связей между инцидентами мы добавили на их форму поле Количество дочерних инцидентов, которое автоматически заполняется при добавлении дочерних инцидентов, а также связанный список Дочерние инциденты.

Подробнее о создании связей инцидентов читайте в документации.

Проверка плановых дат запросов на изменение​

Добавили в запросы на изменение проверку значений полей Плановая дата/время начала и Плановая дата/время окончания на соответствие временным рамкам задач на изменение, связанных с текущим запросом. Если временные рамки запланированных задач на изменение выходят за временные рамки, указанные на форме запроса, то:

  • Под полем Плановая дата/время начала отображается предупреждение с указанием Задачи на изменение с самой ранней датой начала.
  • Под полем Плановая дата/время окончания отображается предупреждение с указанием Задачи на изменение с самой поздней датой завершения.

Новая функциональность позволит менеджерам изменений более эффективно планировать работу по запросам на изменение.

Подробнее о расписании для изменений читайте в документации.

Исправления​

DEF0018974: В предыдущей версии отсутствовала валидация полей Плановая дата/время начала и Плановая дата/время окончания на форме Задачи изменений, что позволяло указывать дату окончания ранее даты начала, в результате чего расчет затраченного времени на работу производился с ошибками. Теперь валидация добавлена исистема не позволяет указать ту же дату окончания, что и дата начала или раньше.