Для разграничения прав доступа к проектам необходимо использовать схемы прав доступа. Можно все проекты привязать к одной схеме прав доступа, а можно для каждого проекта создать индивидуальную схему прав доступа.
Данная статья относится к циклу статей, которые помогут вам внедрить JIRA SOFTWARE в организации.
Первое что требуется сделать, перед тем как создавать схему прав доступа – создать группы в JIRA. После создания групп мы сможем при заведении учётных записей в JIRA привязывать учётные записи к группам. В схемах прав доступа мы сможем выдавать определённым группам определённые права. В схемах прав доступа можно выдавать права и отдельным пользователям, но в этом случае становится трудно управлять схемами прав доступа при росте количества пользователей больше 5-ти человек.
Создание группы
Переходим в раздел администрирования «Управление пользователями» — «Группы»:
На открывшейся странице вводим название группы и нажимаем «Добавить группу»:
В названии группы добавляется слово «Группа», чтобы в фильтрах JIRA можно было с лёгкостью отделить группы:
Аналогичным образом создаём все необходимые нам группы.
Создание схемы прав доступа
Переходим в раздел администрирования «Задачи» — «Схемы прав доступа»:
В данном разделе нажимаем на кнопку «Добавить схему прав доступа» и на открывшейся странице заполняем название и описание, после чего нажимаем «Добавить»:
Далее нам необходимо настроить права доступа к проекту определённым группам, для этого в списке проектов, напротив созданного нами проекта, нажимаем на ссылку «Права доступа»:
Откроется страница редактирования прав доступа. Описывать каждую роль не будем, во-первых это долго, а во-вторых в JIRA есть к ним понятные комментарии. Приведу готовый пример настройки схемы прав доступа, который будет оптимальным для вас (используется мной в работе):
Как видите, у нас в схеме прав доступа фигурируют только группы и роли, и это правильное решение. Не добавляйте в схемы прав доступа отдельных пользователей, так как вы запутаетесь в огромных списках, устанете администрировать и будете на администрирование тратить огромное количество времени.
Расширенное администрирование проекта
В схеме прав доступа есть пункт включения расширенного администрирования. Если включить данную настройку и в проекте назначить администратора, то он сможет изменять бизнес-процесс у запросов по текущему проекту и производить ряд других настроек проекта. Включайте данную настройку, если вы уверены в человеке, который будет администратором проекта.
Создание проектных ролей и предоставление прав доступа ролям
В некоторых разделах у нас есть роли. Что такое роль?
Роль – это сущность, которая позволяет разграничивать права доступа на уровне проекта. К примеру, я назначаю администратором проекта своего пса Шарика. Шарик не имеет доступ к администрированию системы JIRA, однако он как администратор проекта может в настройках самого проекта раздавать права, присваивая определённым пользователям определённые роли. JIRA в свою очередь определяет, что разрешено делать определённой роли, и разрешает производить конкретные операции определённые схемой прав доступа.
В настройках проекта это выглядит следующим образом:
Роли добавляются в разделе администрирования «Система» — «Безопасность: Проектные роли»:
И на открывшейся странице под списком всех ролей имеется форма добавления ролей:
После добавления роли она станет доступной для выбора в схеме прав доступа и в настройках проекта.
О схеме прав доступа сказано достаточно, теперь она может быть привязана к проекту и будет отвечать за доступы к привязанному проекту.
Добавили группу, а она не отображается при выборе наблюдателей в задаче. Почему?
Насколько я знаю стандартные средства JIRA позволяют наблюдателями назначать только определённых пользователей. Заведите групповой ящик почты и учётку в JIRA и эту групповую учётку назначайте в наблюдатели. В этом случае уведомления будут уходить на групповой email и вся группа будет видеть.
Как сделать видимость задачь в jira cloud только для тех, для кого назначена задача ?
Богдан, это возможно реализовать через Схемы безопасности задач в пост функциях перехода между статусами в процессе.