Ситуация следующая:
Есть Заявка №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: В самом обновлении дочерних запросов нет ничего странного, этот функционал описан в инструкции пользователя: User request management (Service Desk) Module [iTop Documentation]. Помимо обновления журналов iTop будет выполнять дочерние тикеты. Аналогично с инцидентами.
По нарядам.
На мой взгляд, ключевая фраза - …“Ответственный за решения тикета мониторит состояние нарядов”. Вот в этом и проблема их использования. Т.е по каждому наряду мне нужно спросить, именно СПРОСИТЬ, а сделал ли ты Вася эту работу? Потому, что указанное время начала и окончания действий по наряду, абсолютно не говорит о том, что наряд будет сделан к этому времени! Мы специально весь ход выполнения работ перенесли в иТоп, чтобы система контролировала выполнено/не выполнено. А мы контролируем благодаря иТопу по контрольным точкам.
Вторая проблема. Когда смотришь на наряды не из Запроса, Инцидента, Проблемы, Изменения, а просто на таблицу нарядов, в ней мы не видим “Клиента”, а без этого поля таблица слабоуправляема. Можно конечно по дате смотреть, но опять таки дата окончания времени по наряду, это как бы “информационное” поле.
По вашей просьбе в модуле управления работами в наряды были добавлены поля Организация и Инициатор, значения которых берется из тикета, к которому привязан наряд.