Когда и как следует использовать роли проекта вместо групп в JIRA?

Question

У меня небольшие затруднения с пониманием, когда человеку следует настраивать разрешения JIRA с помощью групп и когда им следует использовать роли проекта.Я читал онлайн-документацию, однако разница между ними кажется незначительной.

A group кажется достаточно простым.Сгруппируйте пользователей в именованное ведро.Присвойте group одному или нескольким разрешениям в permission scheme, чтобы разрешить доступ к функциям для любых пользователей в группе.Назначьте permission scheme для project, чтобы применить разрешения к этому project.

A project role выглядит очень похоже.Он выполняет все вышеперечисленное, за исключением того, что вы также можете добавить groups к project roles.Кажется, что project role также позволяет администратору проекта добавлять своих собственных пользователей в проект вместо того, чтобы требовать от системного администратора.

Однако я не уверен, как я могу использовать это.Вот пример того, чего я хочу достичь.

1. Создание нескольких проектов в JIRA.
2. Все наши менеджеры, разработчики и т. Д. Имеют одинаковые разрешения для всех проектов.
3. Наши клиенты имеют доступ только к своим проектам.

Я думаю, что лучший способ сделать это:

1. Создать сотрудников group, к которым я добавляю всех наших сотрудников.
2. Создайте одного или нескольких project roles, к которым я добавляю соответствующих клиентов.
3. Назначьтеразрешения для Схемы разрешений по умолчанию с использованием сотрудников group.
4. Скопируйте Схему разрешений по умолчанию в новую схему, специфичную для проекта, например, клиент-схема
5. Назначить клиент-схему для конкретного проекта клиента.

Однако, похоже, я не являюсьиспользуя project role membership.Как это входит в игру?

Как лучше всего использовать JIRA groups и project roles?Чем они отличаются?

Answer 1

Мы советуем работать с ролями, поскольку у этого есть несколько преимуществ

a.Вы можете настроить полную конфигурацию на основе ролей.

Например, у вас может быть «подтвержден» переход рабочего процесса, который может выполнить только тот, кто является тестером.

У вас есть выбор:добавьте условие перехода «пользователь в групповом тестере» или «у пользователя есть тестер ролей».

Если вы работаете в организации, где пользователи играют разные роли в разных проектах, выбор первого условия перехода (пользователь входит в группу тестировщика) не будет работать (или вам потребуется новый рабочий процесс для каждого проекта)

То же самое относится к уведомлениям.
Вы можете настроить уведомление о событии «проблема решена», указав, что «пользователи в групповом тестере» получают уведомления или «пользователи, имеющие тестер ролей».

При использовании ролей добавить кого-либо в проект очень просто - просто проверьте, какую роль играет человек в проекте, добавьте его в конфигурацию проекта (просмотр участников), и все готово.Он будет иметь нужные разрешения, получать нужные уведомления ...

б.Конфигурация

Когда вы используете роли для конфигурации, вам не нужны права системного администратора для добавления кого-либо в проект.Руководитель проекта сможет добавить пользователя.Не нужно беспокоить системного администратора.

---

Глядя на ваше описание, у меня будет

1. Роль проекта «сотрудник»
2. Роль проекта «клиент»
3. Группа «сотрудники»
4. настраивает роль проекта таким образом, чтобы сотрудники группы были членом по умолчанию сотрудника роли проекта

Таким образом, вы можете использовать одну и ту же схему разрешений для всех проектов.При добавлении нового проекта вам просто нужно добавить клиентский идентификатор пользователя в роль клиента.Когда новый сотрудник начинает работу, вы добавляете его в группу сотрудников.

В тот день, когда у вас есть конкретный сверхсекретный проект, к которому требуется доступ только нескольким сотрудникам, вы можете удалить сотрудников группы.'из роли' сотрудник 'и добавьте в нее определенных пользователей.

Надеюсь, это поможет

Фрэнсис

Answer 2

Исторически в JIRA сначала были группы.Затем появились роли, и в большинстве случаев это рекомендуемый способ управления авторизацией.

~ Matt

Answer 3

Группы являются глобальными. Роли можно рассматривать как группы проектов (локальные).

Роли намного лучше: в противном случае с большим количеством проектов вы быстро получите множество групп и схем разрешений (по одной на проект).

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

Но вы получаете большую гибкость. Например, в настоящее время у вас должна быть роль «Сотрудник», которая будет заполняться группой «Сотрудники» для каждого проекта, но по мере роста вашей компании и сложности вы можете иметь разных сотрудников для каждого проекта без необходимости изменять схемы разрешений