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