Ограничение на видимость заявок

[Karapuz]

Всем привет!

Подскажите, возможно ли организовать ограничение видимости заявок для разных агентов в рамках одной очереди по атрибуту клиента "Компания клиента"? Если да, то какими это средствами делается? Куда копать?

Пример:
Очередь "Некоторая очередь" имеет внутри себя 2 заявки
1-я заявка оформлена на клиента с компанией А
2-я заявка оформлена на клиента с компанией Б

Агент А должен видеть в очереди "Некоторая очередь" только 1 заявку с компанией А
Агент Б должен видеть в очереди "Некоторая очередь" только 1 заявку с компанией Б

[ykolesnikov]

Посмотрите в сторону ACL. В качестве условия/фильтра можно установить CustomerID, а про права, надо смотреть в возможные атрибуты в ACL. Смотрите в мануле главу про ACL, особенно Reference (последний раздел про ACL) и поищите здесь на форуме, Алексей давал перечень атрибутов для ACL.

Но вообще, при увеличении количества агентов и компаний это превратится в головную боль. может лучше либо очереди сделать по компаниям клиентов. Много вариантов, главное, понять зачем!

[alexus]

В базовом варианте нельзя ограничивать доступ к тикетам по компаниям. Сама идея такая не очень хороша. Надо тогда очереди делать по клиентам, но такая схема тоже плоха. Если речь идёт именно об использовании OTRS для поддержки, то, видимо, следует искать проблемы в бизнес-логике.

[Karapuz]

Посмотрите в сторону ACL. В качестве условия/фильтра можно установить CustomerID, а про права, надо смотреть в возможные атрибуты в ACL. Смотрите в мануле главу про ACL, особенно Reference (последний раздел про ACL) и поищите здесь на форуме, Алексей давал перечень атрибутов для ACL.

Но вообще, при увеличении количества агентов и компаний это превратится в головную боль. может лучше либо очереди сделать по компаниям клиентов. Много вариантов, главное, понять зачем!

ACL смотрел, но не условия CustomerID не увидел там, поэтому и задался вопросом как можно это сделать иначе, чтобы не разделять по очередям.

В базовом варианте нельзя ограничивать доступ к тикетам по компаниям. Сама идея такая не очень хороша. Надо тогда очереди делать по клиентам, но такая схема тоже плоха. Если речь идёт именно об использовании OTRS для поддержки, то, видимо, следует искать проблемы в бизнес-логике.

Это так сказать временный костыль для текущей бизнес-логики. Только формируется централизация бизнес-процессов по управлению ИТ для двух разных компаний. Поддержка будет осуществляться только сотрудникам компании, о внешних клиентах речь не идет. Адрес электронной почты поддержки пользователей планируется 1, а распределять заявки надо по двум направлениям. Хотелось, чтобы на данный момент все ложилось в 1 очередь 1-я линия например и в ней уже агенты видели только свои заявки по своим компаниям и уже дальше решали их или перенаправляли в очереди 2-й линии уже по направлениям и очередям, возможно разделенным на данный момент очередями. В будущем естественно все станет централизованным.

[alexus]

Тут надо смотреть, каким образом лучше строить поддержку. Я бы не бежал впереди паровоза, а для начала спроектировал бы сервисдеск с учётом текущего состояния и планируемого. А дальше уже можно рассуждать, как настаивать OTRS. У нас была реализация системы с географическии распределённой первой линией, но там это было постоянное решение в связи с распределённостью клиентов по объектам. Вобщем надо сначала думать, планировать, а потом настраивать OTRS.