Результат решения

[JohniGo]

Про коммерческие продукты - согласен конечно, но там хоть теоретически есть документация.
Про решение клиенту - тоже согласен, но пока мне кажется, что написание 2 заметок (внетренней и внешней) все-таки слегка чересчур (хотя в принципе, это правильно наверно).

[ykolesnikov]

Через тернии к звездам!
Коллеги, практический вопрос, думаю, в эту тему.
Как ограничить права на доступ к кнопке Решение для простых агентов и оставить лишь руководителям (имеется в виду утверждение решения, не результат работы) и при этом не заниматься пересылкой заявки между очередями, где у руководителя эксклюзивные права. Можно, конечно, ввести новые, отличные от стандартных, права, поэкспериментировал - работает, но появляются глюки с интерфейсом при описании прав - не помещаются по горизонтали в окошке Группы-агенты и нет горизонтального скроллинга
UPDATE
Покурил (не мануал) и сам нашел решение.
В SysConfig in Ticket -> Frontend::Agent::Ticket::MenuModule добавил ключ(Key)(через "+" Group и Содержание (Content) со списком групп аналогично параметру Ticket::Frontend::MenuModule###460-Delete - например - rw:Менеджер запросов;rw:admin для параметра Ticket::Frontend::MenuModule###420-Decision. Таким образом теперь кнопка Решение будет только у членов этих групп. Заодно стало понятно, что этим можно пользоваться и в других подобных параметрах, а не только где они(такие ключи) явно присутствуют.
Может все об этом уже и так знают, для меня было открытием. Буду рад если кому-то еще будет полезно.
Век живи век учись.
P.S. Единственно, так и не получил ответа на пост: viewtopic.php?f=2&t=477 - какие-то глюки с переводом терминов в окне Решение.

[JohniGo]

Юрий, я правильно понимаю, чот Вы ограничиваете доступ к созданию заемтки - решания, а не к полю согласование в тикете?
Просто мне казалось логичным, что решение как раз пишет агент, а руководитель либо одобряет, либо не одобряет его.

[yuri0001]

Боюсь, мы несколько о разном. Вы правильно поняли, но я имел ввиду о согласовании перед исполнением, а не после. Например, заказчик запросил некий апгрейд, а деньги на него не были включены в бюджет или параметры не соответствуют корпоративному стандарту или политке безопасности. В таком случае заявка может быть направлена руководителю, принимающему решение и он поставит свое решение. А решение после исполнения можно записать и обычной заметкой, даже при закрытии заявки. Пока мне видится так, надо еще подумать. В вашем варианте тоже есть интересный посыл.

[JohniGo]

Мне кажется апгрейд - это уже управление изменениями, а не инцидент. Я так понимаю руководитель, не забирая к себе в очередь пишет решение? Соответсвенно обобряя (давая разрешение) на запрашиваемое клиентом изменение?

[ykolesnikov]

Да, примерно так. Конечно, это изменение, но я, пока с этот процесс не выделяю. Надо разбираться, как это здесь работает, чтобы излишне не заформализовать. На прежней работе, в большой компании, на CA Unicenter, одобрение(согласование) было выполнено через Каталог сервисов и там у сервиса был расписан маршрут согласования, после прохождения которого заявка попадала к исполнителю, а в запросах на стандартные изменения были прописаны маршруты по группам исполнителей, с возможностью параллельных и последовательных работ. Здесь я этого пока не смотрел.

[JohniGo]

в коммерческих продуктах конечно функционала гораздо больше и из коробки (ну пости без напильника), но тут это офтоп, так что строгаем то, что есть.

[ykolesnikov]

Там тоже год на токарном станке точили А у нас: Я тебя слепила из того, что было, ну а ... as is. Ничё, прорвемся!