Авоматизация назначения прав пользователям

[XOT]

Приветствую, коллеги!
OTRS тянет клиентов из AD в 7 бэкэндов, всего выходит около 500 клиентов. Для каждой бэкэнда существует своя очередь и выданы права доступа только на свою очередь. В связи с этим вытекает проблема с назначением прав новым клиентам, т.е. приходится постоянно отслеживать появление новых учёток и выдавать права вручную.
Встаёт вопрос - как автоматизировать процесс назначения прав пользователям по бэкэндам?
Подскажите, товарищи.

[ykolesnikov]

Я, конечно, не специалист по AD, но что-то мне подсказывает, что можно связать некие атрибуты из AD с группами OTRS.
Т.к. права агентам в OTRS раздаются в группах, а они в свою очередь привязываются к очередям. Если я правильно понял и речь идет об агентах, а не клиентах в терминах OTRS.
Возможно, коллеги, сведующие в AD, подскажут конкретнее.

[XOT]

Речь о клиентах. В конфиге я их фильтрую по некому уникальному значению, так же у каждого бэкэнда уникальный домен почты.
Так конкретнее скажите как связать конкретный бэкэнд с конкретной группой в отрс?
Ещё раз повторю суть вопроса - сделать так, чтоб права на группы отрс выдавались автоматом, чтоб не ходить в админку "клиенты-группы".
Подозреваю что есть параметр для файла конфиг.пм, уточните или опровергните.

[alexus]

Мне не очень понятна постановка задачи "верхнего уровня". А именно не ясно, зачем клиентов делить по очередям? Такая бизнес-задача, конечно, иногда встречается, но в общем случае такой подход противоречит принципам построения службы поддержки.

[XOT]

Условно опишу: Есть 7 фирм, у каждой своя служба ИТ. Все фирмы в локалке. Клиенты(сотрудники) фирмы "А" должны видеть только очередь "А", ИТшников которые работаю на фирме "А", и так далее. Соответственно на каждую фирму своя очередь, которую обслуживают свои ИТшники. Ничего странного. Поэтому такое деление всех клиентов(сотрудников) в отрс.
Теперь поможете?

[alexus]

А Ваша роль какова? У этих 7-ми фирм - у каждой своя ИТ-служба? И каждая ИТ-служба имеет доступ в Ваш OTRS? Т.е. вы запустили 1 OTRS на 7 разных компаний? Эти 7 компаний - аффилированные (раз уж они в локалке)? Нарисуйте схему исполнения запросов и их прохождение по очередям.

[XOT]

Со всем уважением не вижу смысла обсуждать это, выйдет очень ёмко.
Я так понимаю можно написать acl. Верно?

[alexus]

Конечно ACL может помочь.

Со всем уважением не вижу смысла обсуждать это, выйдет очень ёмко.

Мое дело предложить.... Просто думаю, что это не первая Ваша проблема. Можно, конечно, и самолет из танка напильником выпилить. Но это не самый эффективный способ. Я не случайно писал

Такая бизнес-задача, конечно, иногда встречается, но в общем случае такой подход противоречит принципам построения службы поддержки.

[XOT]

Как решить эту задачу? Мне нужно именно это.

[alexus]

Автоматом настраиваются права только для агентов. Для клиентов - руками в "клиенты-группы".

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

А где здесь проблема??? Клиент может видеть только свои заявки (или заявки Компании, если настроить).

[XOT]

Проблема в ручной выдаче новому клиенту прав rw на нужную группу.
Подразумевается, что админят отрс только в одной фирме, в остальных фирмах работают просто агенты-исполнители. Отслеживать одному админу появление в остальных 6ти фирмах новых пользователей в AD не представляется возможным.

[alexus]

Зачем клиенту права в группы?

[XOT]

Чтоб видеть только одну свою очередь(очередь "ИТ фирмы "А"").

пример одного бэкэнда(таких несколько):

Код: Выделить всё

$Self->{CustomerUser6} = {
        Name => 'Active_Directory_6',
        Module => 'Kernel::System::CustomerUser::LDAP',
        Params => {
            Host => 'xxx.yyy.aaa.bbb',
            BaseDN => 'DC=yyy,DC=aaa,DC=bbb',
            SSCOPE => 'sub',
            UserDN => 'CN=LDAPUser,CN=Users,DC=yyy,DC=aaa,DC=bbb',
            UserPw => 'qwerty',
			SourceCharset => 'utf-8',
			DestCharset => 'utf-8',
            AlwaysFilter => '(objectCategory=Person)(scriptPath=firma6.vbs)',
            Params => {
                port => 389,
                timeout => 120,
                async => 0,
                version => 3,
            },
        },
        CustomerKey => 'sAMAccountName',
        CustomerID => 'mail',
        CustomerUserListFields => ['cn', 'mail'],
        CustomerUserSearchFields => ['sAMAccountName', 'cn', 'mail'],
        CustomerUserSearchListLimit => 1000,
        CustomerUserPostMasterSearchFields => ['mail'],
        CustomerUserNameFields => ['givenname', 'sn'],
        CustomerUserExcludePrimaryCustomerID => 0,
        AdminSetPreferences => 0,
        Map => [
           [ 'UserSalutation', 'Title',      'title',           1, 0, 'var', '', 0 ],
            [ 'UserFirstname',  'Firstname',  'givenname',       1, 1, 'var', '', 0 ],
            [ 'UserLastname',   'Lastname',   'sn',              1, 1, 'var', '', 0 ],
            [ 'UserLogin',      'Username',   'sAMAccountName',             1, 1, 'var', '', 0 ],
            [ 'UserEmail',      'Email',      'mail',            1, 1, 'var', '', 0 ],
            [ 'UserCustomerID', 'CustomerID', 'mail',            0, 1, 'var', '', 0 ],
            [ 'UserPhone',      'Phone',      'telephonenumber', 1, 0, 'var', '', 0 ],
            [ 'UserAddress',    'Address',    'postaladdress',   1, 0, 'var', '', 0 ],
            [ 'UserComment',    'Comment',    'description',     1, 0, 'var', '', 0 ],
        ],
    };

[alexus]

Зачем ему видеть только свою очередь? Чего Вы хотите этим добиться? Просто отвлекитесь от технической реализации. Когда я спрашиваю "в чем задача?", я имею ввиду не техническое решение, а алгоритм и процесс работы. В чем практический смысл разнесения тикетов по очередям? Чтобы их видели только свои ИТ-шники? Тогда просто сортируйте тикеты в соответствующие очереди по совпадению доменного имени и всё! Зачем вообще клиенту в личном кабинете в этом случае давать выбор очереди?

[XOT]

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

Допустим всем клиентам по умолчанию будет доступна только группа по умолчанию "users" и связанная очередь "all_tickets"(тоесть ничего не нужно вручную трогать при заведении новой учётки в AD), после сортировки тикет попадёт в очередь "it-3". Клиент сможет видеть и отвечать в своём тикете?

[alexus]

Если не включать механизм "Клиенты-группы", то клиент будет видеть свои заявки в ЛЮБОЙ очереди!

[XOT]

Ах вот в чём дело. Спасибо! Попробую такую схему.

[XOT]

Настроил по данной схеме, отлично.
Столкнулся с проблемой уведомлений о поступлении нового тикета. Уведомление агентов(AdminNotification) работает, но отсылает на почту почему-то только агентам, которые находятся он-лайн в отрс. Как побороть это?
А через Уведомление о событии(AdminNotificationEvent) вообще не нашёл событие, которое бы отрабатывало перемещение тикета через GenericAgent.

[alexus]

TicketQueueUpdate