Разница в типе связей заявок Обычный и Родитель-Потомок

[xpasha]

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

[ykolesnikov]

Все получается. Надо только активировать параметр:
Редактировать настройки конфигурации in Ticket -> Core::TicketACL --> Ticket::Acl::Module###1-Ticket::Acl::Module
ACL модуль, который позволяет закрывать родительские заявки только после того как все младшие закрыты ("State" задает доступные состояния для родительских заявок до закрытия всех младших. (никакого ACL создавать не надо, это встроенный ACL, который только надо активировать).
Надо только иметь в виду, что эта настройка не работает, если дополнительно в системе присутствует дополнительный пакет OTRS Master/Slave. (По крайней мере так было. Давно не проверял.).
Это удобно, например, при разделении заявки, когда надо, чтобы родительскую можно было закрыть только после выполнения порожденной/ых.
Более сложным, но и более функциональным, механизмом является использование Управления Изменениями. Там настраивается State Machine (таблица состояний/переходов) для WorkOrder'ов, но это отдельная песня.

[xpasha]

Немножно в сторону от темы... Я попробовал функционал Master/Slave. Я почему-то был уверен, что должна быть возможность блокировки закрытия мастер-заявки, если не закрыта слейв, однако можно закрыть и мастер, тогда автоматически закроется слейв. Возможна ли обратная связь по закрытию слейв->мастер, но невозможность закрыть мастера пока не закрыт слейв? Могут ли заявки в связке мастер-слейв принадлежать разным владельцам. Практическая задачка состоит в том, что инженер ТП получив заявку, может создать дочернюю на решение связанной проблемы силами другого подразделения передав ее туда, там в отдельной очереди ее поднимут на исполнение заблокировав на исполнителя, и пока это подразделение не закроет заявку, инженер ТП не сможет закрыть свою.

[xpasha]

Разобрался... после того как включил ACL на парент-чайлд в мастере просто пропал пункт закрытия заявки.. Похоже модуль Master/Slave сильно завязан на механизм связки обьектов уже присутствующий в составе OTRS.

[ykolesnikov]

Про Master/Slave ничего не могу сказать. Давно пробовал, но, в результате отказался. Возможно, не до конца понял, возможно не настроил правильно, но остался сумбур в голове. Возможностей, вроде много но, не все очевидно и при работе не очень удобно. Поэтому остановился на разделении заявок, что дает схожие возможности, но нагляднее и проще для наших агентов. Поэтому, тему Master/Slave для себя закрыл. При разделении, единственно, надо принять для себя некое правило, от чьего имени создавать разделенную заявку (есть возможнось либо выбрать клиента, создавшего родительскую заявку, либо агента/клиента - разделяющего ее. Это связано с тем, кому будут поступать уведомления по заявке потомку и хотим ли мы посвящать клиента родительской заявки в эту кухню).

[xpasha]

В результате своих экспериментов я тоже пришел к выводу, что Master/Slave менее предпочтителен, чем Split. В случае с Master/Slave нужно запомнить номер заявки, которая будет мастером, создать новую и связать с мастером. Все это несколько неудобно, надо копипастить номер мастер-заявки, открывать отдельное окно для создания новой заявки. В случае с разделением окно появляется само и уже автоматически связывается с родительской заявкой, кроме того между родительской и дочерней заявкой также работают правила определяемые в сисконфиге для линковки объектов. Так что предварительно останавливаюсь на разделении. Спасибо за помощь.