Версия 1.14.0
Перед развертыванием версии ITSM 1.14.0 убедитесь, что у вас установлена версия платформы 1.22.6 или более поздняя версия.
В новой версии мы добавили возможность использовать электронную почту в качестве источника для системы мониторинга, улучшили логику классификации запросов на обслуживание, доработали логику связывания дочерних и родительских инцидентов, а также внесли улучшения и исправления в логику работы с запросами на изменение.
Новая функциональность
Обработка почтовых сообщений от систем мониторинга
Дополнили модуль управления событиями мониторинга функциональностью создания событий из почтовых сообщений, что существенно расширяет сферу возможного применения механизма обработки событий мониторинга.
Для этого мы добавили новый тип источника мониторинга – Письма, который позволяет получать сообщения от систем мониторинга, не поддерживающих отправку JSON. Чтобы использовать письма как источник мониторинга, настройте парсинг почтовых сообщений и подготовку на их основе данных в формате JSON для дальнейшей обработки системой в дополнительном шаге мастера создания нового источника мониторинга.
Подробнее о настройке источников мониторинга читайте в документации.
Смотрите видео с обзором новой функциональности.
Чтобы узнать больше о модуле Мониторинг и управление событиями, смотрите обзорное видео.
Классификация запроса на обслуживание по услуге
В этой версии появилась возможность классификации запроса на обслуживание по услуге, что особенно удобно когда в Каталоге услуг присутствует сложная иерархия родительских и дочерних услуг.
Для этого мы добавили на форму запроса на обслуживание новое поле Основная услуга. Если оно заполнено, то в поле Услуга для выбора будут доступны только те услуги, у которых основная услуга совпадает с указанным значением. Если поле Основная услуга не заполнено, то в поле Услуга для выбора доступны все значения из каталога.
Вы можете скрыть поле Основная услуга с формы при помощи нового системного свойства.
Подробнее о запросах на обслуживание читайте в документации.
Смотрите видео с обзором новой функциональности.
Улучшения
Доработки связи родительских инцидентов с дочерними
Мы улучшили логику связывания родительских инцидентов с дочерними для более удобной массовой обработки записей инцидентов по одному событию.
Для этого мы внесли следующие изменения:
- Добавлять дочерние инциденты теперь можно только к инфраструктурным инцидентам.
- Дочерний инцидент можно привязать к другому инциденту, только если последний не является дочерним.
- При смене статуса родительского инцидента статус дочерних инцидентов автоматически меняется на тот же статус, что и у родительского.
- При переводе родительского инцидента в статус Завершено и сохранении записи содержимое вкладки Информация о закрытии копируется в соответствующие поля дочерних инцидентов.
- Также синхронизируются поля:
- Влияние
- Срочность
- Приоритет
- Назначено на группу
- Кому назначено
Кроме того, мы добавили системное свойство itsm.itsm_incident.map_assigned_group_and_user_to_children, которое позволяет отключить синхронизацию полей Кому назначено и Назначено на группу (по умолчанию синхронизация включена).
Для более удобного отслеживания связей между инцидентами мы добавили на их форму поле Количество дочерних инцидентов, которое автоматически заполняется при добавлении дочерних инцидентов, а также связанный список Дочерние инциденты.
Подробнее о создании связей инцидентов читайте в документации.
Проверка плановых дат запросов на изменение
Добавили в запросы на изменение проверку значений полей Плановая дата/время начала и Плановая дата/время окончания на соответствие временным рамкам задач на изменение, связанных с текущим запросом. Если временные рамки запланированных задач на изменение выходят за временные рамки, указанные на форме запроса, то:
- Под полем Плановая дата/время начала отображается предупреждение с указанием Задачи на изменение с самой ранней датой начала.
- Под полем Плановая дата/время окончания отображается предупреждение с указанием Задачи на изменение с самой поздней датой завершения.
Новая функциональность позволит менеджерам изменений более эффективно планировать работу по запросам на изменение.
Подробнее о расписании для изменений читайте в документации.
Исправления
DEF0018974: В предыдущей версии отсутствовала валидация полей Плановая дата/время начала и Плановая дата/время окончания на форме Задачи изменений, что позволяло указывать дату окончания ранее даты начала, в результате чего расчет затраченного времени на работу производился с ошибками. Теперь валидация добавлена и система не позволяет указать ту же дату окончания, что и дата начала или раньше.