Когда и как следует использовать проектные роли вместо групп внутри JIRA?
Мне немного трудно понять, когда человек должен настроить разрешения JIRA с помощью групп, а когда они должны использовать роли проекта. Я читал онлайн-документацию, однако разница между ними кажется тонкой.
A group кажется достаточно простым. Группируйте пользователей в именованное ведро. Назначьте group одному или нескольким разрешениям в permission scheme, чтобы разрешить доступ к функциям для всех пользователей в группе. Назначьте permission scheme a project, чтобы применить разрешения на это project.
A project role кажется очень похожим. Он делает все вышеперечисленное, за исключением того, что вы также можете добавить groups к project roles. Похоже, что project role также позволяет администратору проекта добавлять своих собственных пользователей в проект вместо того, чтобы требовать системного администратора.
Тем не менее, я не уверен, как я могу использовать это. Вот пример того, чего я хочу достичь.
- Есть несколько проектов, созданных в JIRA.
Все наши менеджеры, разработчики и т. д. иметь одинаковые разрешения для всех проектов.
Наши клиенты имеют доступ только к своим проектам.
Я думаю, что лучший способ добиться этого - это:
- создать сотрудников
groupк которым я добавляю всех наших сотрудников. - создайте один или несколько
project rolesк которым я добавляю соответствующих клиентов. - назначьте разрешения схеме разрешений по умолчанию с помощью сотрудников
group. - копия схема разрешений по умолчанию для новой схемы конкретного проекта, например, клиентская схема
- назначьтесхему клиента конкретному проекту клиента.
Однако, похоже, что я не использую project role membership. Как это вступает в игру?
Какова наилучшая практика использования JIRA groups и project roles? Чем они отличаются друг от друга?
3 ответов:
Мы советуем работать с ролями, так как это имеет несколько преимуществ
A. Вы можете настроить полную конфигурацию на основе ролей.
Например, у вас может быть "проверенный" переход рабочего процесса, который может быть выполнен только тем, кто является тестировщиком.
Вы можете добавить условие перехода "пользователь находится в тестере групп" или "пользователь имеет тестер ролей".
Если вы работаете в организации, где пользователи выполняют разные роли в разных проектах, выбор первого условия перехода (пользователь находится в тестере группы) не будет работать (или вам потребуется новый рабочий процесс для каждого проекта)
То же самое относится и к уведомлениям.
Вы можете настроить уведомление о событии "проблема решена", указав, что "пользователи в тестере групп" получают уведомление или "пользователи, у которых есть тестер ролей".При использовании ролей добавить кого-то в проект очень просто-просто проверьте, какую роль человек играет в проекте, добавьте их в проект настройка (просмотр участников) - и готово. Он будет иметь правильные разрешения, получать правильные уведомления ...
B. Конфигурация
Когда вы используете роли для настройки, вам не нужны права системного администрирования, чтобы добавить кого-то в проект. Руководитель проекта сможет добавить пользователя. Нет необходимости беспокоить системного администратора.
Глядя на ваше описание, я бы
- роль проекта "сотрудник"
- роль проекта "клиент"
- группа "сотрудники"
- настройте роль проекта таким образом, чтобы группа employees была членом роли проекта employee по умолчанию.
Таким образом, вы можете использовать одну и ту же схему разрешений для всех проектов. При добавлении нового проекта вам просто нужно добавить клиентский идентификатор пользователя в роль клиента. При запуске нового сотрудника вы добавляете его в группу сотрудников.
День, когда у вас есть конкретный, сверхсекретный проект, где всего пара сотрудники должны иметь доступ, вы можете удалить группу "сотрудники" из роли "сотрудник" и добавить конкретных пользователей в роль.
Надеюсь, это поможет
Фрэнсис
Исторически у Джиры были группы первыми. Затем появились роли, которые в большинстве случаев являются рекомендуемым способом управления авторизацией.
~Matt
Группы являются глобальными. Роли можно рассматривать как группы по проекту (локальные).
Роли намного лучше: в противном случае с большим количеством проектов вы быстро получите множество групп и схем разрешений (по одному на проект).
Вы ничего не теряете, используя схемы разрешений на основе ролей, поскольку вы можете добавить группу к роли.
Но вы получаете большую гибкость. Например, в настоящее время роль сотрудника будет заполнена вашей группой сотрудников для каждого но поскольку ваша компания и сложность растут, вы можете иметь разных сотрудников для каждого проекта, не меняя схемы разрешений
Comments