Я новичок в этом понятии системы тикетов OTRS / Help.
Будем признательны, если кто-нибудь может предоставить простой пример, который различает пользователя в группе и пользователя, связанного с ролью в OTRS. И что делает использование одного из них более или менее выгодным по сравнению с другим.
Длинный ответ:
Резюме:
Авторизация - набор из пары {(пользователь, ресурс, действие)} Предоставление - (ресурс, действие)
Группы - это наборы людей (пользователей). Роли - это набор разрешений.
Объяснение: Группы и роли - это запутанное и запутанное понятие. Я обнаружил, что если есть какой-либо консенсус, то оба они используются для подключения пользователей и разрешений (возможность действовать на каком-либо ресурсе). В конечном итоге вся авторизация связана с подключением пользователя, ресурса и действия; например, Джейн и зарезервировать билет на рейс 123 American Airlines ... Пользователь - Джейн, ресурс - AA 123, действие - резервирование. Думайте об этом как о большой трехмерной таблице или матрице, с одной стороны у нас есть пользователи, с другой - ресурсы, а с третьей стороны - действия. Это очень быстро становится большим. Чем точнее мы распределяем ресурсы, тем больше проблема администрирования.
Чтобы уменьшить эту матрицу, мы объединяем похожих пользователей в именованные сегменты и называем их группами. Мы объединяем разрешения на ресурсы и действия и вызовы, а также объединяем наборы этих разрешений и называем их ролями. Идея в том, чтобы сделать стороны (размеры) матрицы меньше. Теперь мы можем преобразовать старую матрицу в одну из ролей и групп для управления авторизацией.
Я обнаружил, что такой взгляд на проблему делает ее управляемой. К сожалению, реальный мир сложен, и иногда люди хотят администрировать систему, в которой они добавляют пользователей в роли и возможности (ресурсы и действия) в группы, и именно эта целесообразность делает роли и группы такими запутанными.
Похоже, что в OTRS есть некоторая семантическая путаница по этому поводу - «группы» и «роли», созданные по умолчанию, перекрываются ... Документация по пользователям, группам и ролям OTRS:
Роли - это очень мощная и полезная функция, позволяющая очень просто и быстро управлять и изменять права доступа многих пользователей. В больших и сложных системах с большим количеством пользователей, групп и очередей эта функция очень полезна и помогает сэкономить время.
...
Вы не должны одновременно использовать сопоставления «Пользователь - группа» и «Пользователь - роль», это значительно усложнит обслуживание. Поэтому, если вы решите использовать роли, мы рекомендуем вам отключить опцию Пользователи <-> Группы в области администратора ...
Обновить:
для каждой компании у них обычно 2 агента - основной (главный человек, который отвечает на проблемы) и дополнительный (действует как кто-то, кто ловит переполнение, если это большая работа и т. д.). Моя проблема в том, чтобы найти лучший способ применить OTRS к этой ситуации самым простым и практичным способом.
Учитывая, что сопоставления ролей и групп не предназначены для совместного использования (если бы они были, вы могли бы сделать что-то вроде Group_<Company> + Role_<Primary|Secondary>) вам, вероятно, придется назначить Role_<CompanyName>_<Primary|Secondary>
Я действительно не вижу здесь проблемы ...
«Группы» - это группы разрешений, и вы можете добавлять пользователей в группы разрешений напрямую или делать это через роли. Последний вариант самый простой, особенно в системах с большим количеством пользователей.
Если вы используете роли, вы можете быстро назначить множество пользователей одной роли, а затем, если вам нужно добавить группу или около того, просто добавьте эту группу к роли один раз вместо того, чтобы вручную добавлять ее всем пользователям, которые могут или может не потребоваться доступ.
Кроме того, если у вас (полу) сложная структура разрешений, использование ролей в отличие от групп обычно НАМНОГО проще, чтобы получить назначение разрешений прямо за один раз - гораздо проще думать: «О да, этот парень должен получить Role_Helpdesk и Role_Incident_Manager вместо того, чтобы запоминать «Это RW в службе поддержки, Примечание плюс права move_into в сети, Примечание плюс move_into в управлении системами и снова RW в уведомлениях» ...
Вы уловили идею?
- Майк
Проще говоря, вы используете группы для прав доступа и роли для управленческих должностей, таких как: администратор, менеджер, колл-центр и т. Д., Затем вы можете назначить им группы прав доступа к часто задаваемым вопросам, телефонным билетам или электронным письмам и т. Д.