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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1 Симпатия

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