OTRS.ru

Имеется OTRS 5
Клиенты авторизуются через LDAP, в систему подтягивается ряд их атрибутов, заполненных в свойствах учётных записей AD.
Задача - ограничить пользователю список доступных очередей, куда он может направит заявку. На текущий момент это, условно говоря, общая очередь службы поддержки и очередь собственного подразделения. Наименования очередей подразделений имеют вид "x.y.z department_name" - т.е. код подразделения и его текстовое название. В атрибутах пользователя есть и то, и другое.
Казалось, бы всё просто: берёшь из атрибутов CustomerUser код подразделения и в разделе Possible для Ticket - Queue - Name вставляешь (строго или по RegExp) это самое значение из атрибутов клиента. Однако мне никак не удаётся заставить ACL "увидеть" или "понять" это самое значение.
Если напрямую указываешь, если, мол, код подразделения клиента равен "х.х.х", то разрешить очередь "[regexp]х.х.х" - всё работает.
Но очередей-то не десяток и не два (да, я знаю, что это плохо, но сейчас это неизбежно).
На текущий момент (куда ж деваться, работать-то должно всё уже сейчас) пришлось создать несколько десятков таких фильтрующих ACL
Это неимоверно коробит и унижает, особенно, когда подозреваешь, что можно было обойтись одним-единственным, который понимает переменные.

Можно ли как-то унифицировать эту часть ACL??? (в 'UserDepartmentCode' попадает значение поля 'departmentNumber' из учётной записи пользователя в AD)

ACL не может подставлять найденные значения в другие свои части. Так что вариантов нет - надо плодить и настраивать. Или кастом делать.

Спасибо за ответ - пусть он и подтвердил мои худшие подозрения.

Надеюсь, кадровая структура (а, значит, и количество очередей и ACL для их обслуживания) не будет расти.
"Горшочек, не вари!!!"

А зачем каждому подразделению своя очередь? Обычно очереди отражают структуру служб поддержки, а не всей компании.

Куча очередей - из-за того, что используются заявки с согласованием непосредственных руководителей пользователей. Например, посылает человек заявку на предоставление ему интернета. По исторически сложившемуся регламенту полагается подтверждение легитимности этой заявки непосредственным руководителем человека. Вот и не придумали ничего лучше как продублировать структуру подразделений в очередях. Человек создаёт заявку, направляя её в очередь своего отдела; за очередью, в свою очередь (каламбур, хе) следит тот самый начальник, который и должен наложить резолюцию, что Имярек достоин доступа к этой услуге.
После резолюции начальника заявка идёт дальше - безопасникам, айтишникам...

MArsMax писал(а):Куча очередей - из-за того, что используются заявки с согласованием непосредственных руководителей пользователей. Например, посылает человек заявку на предоставление ему интернета. По исторически сложившемуся регламенту полагается подтверждение легитимности этой заявки непосредственным руководителем человека. Вот и не придумали ничего лучше как продублировать структуру подразделений в очередях. Человек создаёт заявку, направляя её в очередь своего отдела; за очередью, в свою очередь (каламбур, хе) следит тот самый начальник, который и должен наложить резолюцию, что Имярек достоин доступа к этой услуге.
После резолюции начальника заявка идёт дальше - безопасникам, айтишникам...

Для таких случаев можно озвучить несколько вариантов:
- процессные заявки
- платные дополнения про workflow
- ITSMChangeManagement - Управление Изменениями (есть в OTRS::ITSM)
Наверное, есть еще. Изучайте, выбирайте.

Ну так там и используются процессные заявки. Платные модули в принципе не приемлют, так что пока, увы "не наш метод".
Затык просто возник в том, что не удалось заставить OTRS автоматически назначать владельца созданной заявки на основании данных клиента.
Всё, вроде бы есть: и информация о клиенте (отдел, должность) и относительно чёткий алгоритм по определению согласующего начальника. Реализация подвела Непонятно, как оперировать этими данными внутри OTRS.

DynamicFieldFromCustomerUser::Mapping и Ticket::EventModulePost###950-DynamicFieldFromCustomerUser переносят атрибут клиента в динамическое поле, делая его таким образом атрибутом тикета. А дин. поля можно уже планировщиком без проблем обрабатывать.