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

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

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

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

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

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

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

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

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

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

7
jira

3 ответов

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

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

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

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

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

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

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

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

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

глядя на ваше описание, я бы

  1. роль проекта "сотрудник"
  2. роль проекта "клиент"
    3. группа''
  3. настройте роль проекта таким образом, чтобы группа employees была членом роли проекта employee по умолчанию

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

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

надеюсь, что это помогает

Франциск

6

исторически у Джиры были группы первыми. Затем появились роли,и в большинстве случаев рекомендуется контролировать авторизацию.

~Мэтт

3

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

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

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

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

1