iTop ITSM & CMDB по-русски

Родительские запросы и наряды на работы

#1

Ситуация следующая:
Есть Заявка №1, из нее создан “Родительский запрос”- Заявка №2. Если в Заявке №2 отписаться в журналах (общий и внутренний), то эти записи дублируются и в Заявку №1. Класс.
Из Заявки №2, создаем “Родительский запрос”- Заявку №3. Изменения в журналах Заявки №3 не дублируются никуда…
т.е. логика нарушена. Вопрос так и надо или…?

Где то в процессе этих экспериментов, звонит Клиент и говорит - “Я на портале не вижу свою Заявку №1”. У Клиента профили - Portal user и Portal power user.
Проверил под его Логином, да действительно, мы видим Заявку №1, а на портале ее нет.
В чем проблема?

#2

Добавлю еще вопрос
Что такое Наряды в иТопе,для чего они!? Логика по ним не понятна.
Почему у этих нарядов нет состояния “Закрыт”?

#3

Наряды - это те самые работы, для которых мы разрабатываем отдельный модуль тут: Совместная разработка Модуля Планирования работ. Протирка пыли, замена коммутатора, установка нового оборудования - всё это оформляется через Наряд на работы. Наряды приходят из любого другого типа тикетов: Запроса, Инцидента, Проблемы или Изменения. А статус “Закрыт” им не нужен. Работа может быть выполнена или не выполнена, а закрывается родительский тикет по результатам одного или нескольких нарядов.

По поводу родительских запросов, сможете повторить тут: http://demo.itop-itsm.ru? Логин/пароль - admin/admin. Или в личку киньте доступ.

#4

На этом уровне я понимаю, что такое наряды. Я понимаю, что у наряда есть время начала и окончания, но проблема в том, что я несколько раз создавал наряд из Запроса и ни разу запрос не был закрыт. Мне это и показалось не логичным. Мало того что нет возможности закрыть Наряд, но он никак и не влияет на Запрос, спрашивается тогда зачем он нужен?
Вы пишите - “…закрывается родительский тикет по результатам одного или нескольких нарядов”. Каким образом? У нас наряды созданные из Заявки ее не закрывают…

#5

Руками. В рамках одного тикета (Запрос, Инцидент, Проблема, Изменение) может быть несколько нарядов с разными сроками и исполнителями. Ответственный за решения тикета мониторит состояние нарядов, а после их выполнения, убеждается в том, что тикет решен и закрывает его.

#6

Ваша заявка №3 не привязана к заявке №2, потому записи в журнале не дублируются. Это произошло потому что после создания родительского запроса №3 (это делается при редактировании дочернего) дочерний запрос №2 не был сохранен. Это видно из Историй запросов.

Где-то в процессе этих экспериментов кто-то указал Инициатором заявки себя. Поэтому клиенту эта заявка стала недоступна. Кто и когда это сделал посмотрите в Истории.

UPD: В самом обновлении дочерних запросов нет ничего странного, этот функционал описан в инструкции пользователя: https://wiki.openitop.org/doku.php?id=2_2_0:datamodel:itop-request-mgmt#regrouping_user_request. Помимо обновления журналов iTop будет выполнять дочерние тикеты. Аналогично с инцидентами.

#7

По нарядам.
На мой взгляд, ключевая фраза - …“Ответственный за решения тикета мониторит состояние нарядов”. Вот в этом и проблема их использования. Т.е по каждому наряду мне нужно спросить, именно СПРОСИТЬ, а сделал ли ты Вася эту работу? Потому, что указанное время начала и окончания действий по наряду, абсолютно не говорит о том, что наряд будет сделан к этому времени! Мы специально весь ход выполнения работ перенесли в иТоп, чтобы система контролировала выполнено/не выполнено. А мы контролируем благодаря иТопу по контрольным точкам.
Вторая проблема. Когда смотришь на наряды не из Запроса, Инцидента, Проблемы, Изменения, а просто на таблицу нарядов, в ней мы не видим “Клиента”, а без этого поля таблица слабоуправляема. Можно конечно по дате смотреть, но опять таки дата окончания времени по наряду, это как бы “информационное” поле.

По родительским запросам, ошибку понял спасибо.

#8

Все!
Снял вопрос по нарядам. Оказывается они Закрываются. В наряде по кнопке Другие действия.

#9

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

1 Симпатия
#10

Спасибо.
Погрузились в изучение.