Стандартный функционал ACL (Access Control Lists) позволяет открыть новые возможности известного решения по автоматизации процессов управления ИТ OTRS. В данном посте я не буду приводить конкретные примеры, которые достаточно подробно описаны в стандартной документации — doc.otrs.org/3.2/en/html/customization.html#acl. Редкий настоящий админ дочитывает до конца хотя бы вводную часть любого мануала. И совершенно напрасно!
Я постараюсь разъяснить именно основы и принципы использования ACL, чтобы каждый смог более эффективно решать свою задачу.
Для чего это нужно?
Допустим, вы уже используете OTRS и активно работаете, создавая новые заявки самостоятельно, предоставляя форму регистрации тикета в личном кабинете клиента. Ваши специалисты уже при работе с тикетом используют TicketZoom и назначают приоритеты, статусы, сервисы, SLA, пишут, перемещают тикеты и закрывают их.
Казалось бы, все хорошо и чего еще пожелать? Но вдруг вы или ваш босс решает:
И вот тут на помощь приходят ACL. Принцип действия ACL предельно прост. Конфигурирование ACL производится только в файле Config.pm. Формат ACL достаточно прозрачен и описан в документации.
Как это работает?
Каждый ACL состоит из 2-х принципиальных частей:
Properties в качестве значений может использовать:
Possible(Not) в качестве значений может использовать:
Синтаксис описан подробно в мануале, так что разложить что к чему по полочкам труда не составит. Главное – это идея. Таким образом, ACL могут, например:
Рекомендую всем без исключения, прежде чем начинать сразу создавать ACL, разрисовать для начала их хотя бы на листе бумаги. У ACL такое свойство – они выполняются все, если не указано
Так что проектирование ACL – залог успешной реализации.
Успехов!
Я постараюсь разъяснить именно основы и принципы использования ACL, чтобы каждый смог более эффективно решать свою задачу.
Для чего это нужно?
Допустим, вы уже используете OTRS и активно работаете, создавая новые заявки самостоятельно, предоставляя форму регистрации тикета в личном кабинете клиента. Ваши специалисты уже при работе с тикетом используют TicketZoom и назначают приоритеты, статусы, сервисы, SLA, пишут, перемещают тикеты и закрывают их.
Казалось бы, все хорошо и чего еще пожелать? Но вдруг вы или ваш босс решает:
- разделить полномочия по осуществлению различных операций над тикетов
- ограничить выбор статусов в зависимости от типа тикета (Инцидент, Проблема)
- ограничить возможность для ваших сотрудников в зависимости от Роли или Группы использовать те или иные типы тикетов и приоритеты
- ограничить возможность для клиентов регистрировать тикеты с типами, кроме как «Инцидент» и «Запрос на обслуживание»
- и многое другое, что часто приходит в голову умным начальникам или просто обусловлено спецификой вашей службы/компании
И вот тут на помощь приходят ACL. Принцип действия ACL предельно прост. Конфигурирование ACL производится только в файле Config.pm. Формат ACL достаточно прозрачен и описан в документации.
Как это работает?
Каждый ACL состоит из 2-х принципиальных частей:
- Условие его применения — Properties.
- Действия по ограничениям -Possible (или PossibleNot).
Properties в качестве значений может использовать:
- текущие параметры тикета (очередь, сервис, статус, приоритет и т.д.)
- текущие свойства агента – логин, роль, группа
- текущие свойства клиена – логин, группа
- текущий элемент интерфейса (Новая телефонная заявка, TicketZoom, CustomerTicketMessage)
Possible(Not) в качестве значений может использовать:
- свойства тикета (очередь, сервис, статус, приоритет и т.д.)
- Action – пункты меню внутри TicketZoom
Синтаксис описан подробно в мануале, так что разложить что к чему по полочкам труда не составит. Главное – это идея. Таким образом, ACL могут, например:
- запретить закрытие тикета для определенных групп или ролей агентов
- разрешить выбирать типы тикетов Проблема только для определенной группы агентов
- оставить клиентам возможность выбора только определенных типов тикетов
- запретить все действия по тикету, если у него не выбран тип и сервис
Рекомендую всем без исключения, прежде чем начинать сразу создавать ACL, разрисовать для начала их хотя бы на листе бумаги. У ACL такое свойство – они выполняются все, если не указано
StopAfterMatch =>1 внутри одного из них. При чем они выполняются в алфавитном порядке их наименования.Так что проектирование ACL – залог успешной реализации.
Успехов!