Практическая социология в JIRA
Практическая социология в JIRA
Что, зачем и почему
В данной статье Anton Chemlev попробует разобраться кто есть кто в JIRA: пользователи, группы, роли и т.п. Тема достаточно сложная и многие пользователи/администраторы путаются. Цель статьи такова - после ознакомления с текстом у читателя должно сформироваться общее понимание устройства пользовательской, групповой и ролевой модели JIRA.
ВАЖНО: Мы говорим о версии Jira > 7.X.X, так именно в 7-ке появились изменения в пользовательской модели.
Многие начинающие, да и продолжающие пользователи Jira, путаются в обилии системных сущностей, представляющих пользователей, их группировку, роли и т.п. Между тем, у каждой такой сущности есть свои области применения в рамках системы и сложившиеся рецепты использования. Для начала давайте составим список того, в чем нам предстоит разобраться, итак:
Далее предлагаю брать поочередно каждую сущность и разбирать, что она из себя представляет по такому шаблону:
- Описание
- Использование в системе
- Как правильно готовить
User
Описание
Все очень просто - User (Пользователь) это основная боевая единица в системе, олицетворяющая конкретную персону. User = учетная запись. User может быть создан как внутри (Internal Directory), так и получен извне (один из вариантов подключения - LDAP Connector, Delegated LDAP, Atlassian Crowd (сюда же отношу и использование другой Jira в качестве поставщика учеток)).
Пользователь может находиться в 2-х состояниях - Active и Inactive. В случае если пользователь Active и состоит в одной из групп, имеющих Application Access, то тогда "сжирается" 1 лицензия. Также пользователь может быть удален, об этом ниже.
Использование в системе
Используется повсеместно, так как issue создаются, выполняются, комментируются и т.п. именно сущностью User. Если быть точным, то User - это экземпляр класса Application User. Сущность используется в схемах: Permission scheme, Notification scheme, Issue security scheme. Кроме того, в workflow можно использовать User в conditions, validators, post-functions. Например, настроить процесс так, чтобы определенный переход мог быть выполнен только определенным User (сразу оговорюсь, что так можно делать, но не нужно - лучше не завязываться на конкретную личность, ибо люди имеют свойство увольняться, болеть и т.п.).
Как правильно готовить
- Придумать naming convention. Например, name.surname или что-то подобное. Если пользователи тянутся из LDAP, то тогда уже ничего не сделаешь. Но если нет - обязательно следовать naming convention, так как далее будет проще использовать имена в скриптах, например.
- Не удалять пользователя, если он уже работал в системе и создавал контент. Нужно просто его деактивировать.
- Следить за активностью пользователей, особенно если у вас большая инсталляция, и не настроена интеграция с LDAP, при которой пользователи автоматически деактивируются при деактивации их в LDAP. Проще всего это делать раз в несколько месяцев, выгрузив из БД список пользователей с датами создания, обновления, последнего логина и деактивировав ненужных уже пользователей. Только учтите, что данные по последнему логину могут быть не совсем корректными, если пользователь при последнем логине поставил чек-бокс Remember me. В таком случае датой последнего логина будет являться как раз дата, когда он решил использовать Remember me. По умолчанию запоминается на 14 дней.
- Не быть жадиной и создать технического/-их пользователей для автоматического выполнения скриптов и интеграций.
Group
Описание
Тоже простая концепция - это объединение пользователей в некое множество по какому-либо признаку. Группы могут как создаваться локально, так и тянуться из LDAP, либо все вместе.
Использование в системе
Использование также повсеместное, как и у User, использование в схемах и процессах тоже аналогичное. Но есть важное отличие: именно группе/-ам предоставляется Application Access, оно же - право логина в систему. Какая-либо из групп, указанных в Application Access может быть назначена default, пользователи будут попадать в эту группу при создании. По умолчанию это группа jira-core-users или jira-software-users, создаваемые системой наряду с группой jira-administrators.
Как правильно готовить
- Naming convention. В случае с группами это становится еще более важным, так как в отличие от User редактировать имя группы нельзя - только создавать заново, переносить пользователей, прописывать в конфигурации проектов и т.п. Один из рекомендуемых форматов: jira-group-name.
- Продумать группы каких типов у вас будут. Исходя из своего опыта могу предложить такую классификацию:
- Группы-структурные подразделения. Практически всегда удобно, за исключением случаев, когда очень большая вложенность.
- Группы-проектные команды. Кроссфункциональные команды, работающие над проектом.
- Функциональные группы. Например, деление на группы аналитиков, разработчиков, тестировщиков и т.п. Немного напоминает первый пункт, но все зависит от сложности орг.структуры и принятых правил работы.
- Группы-разрешения (коряво звучит, но пусть так). Сюда можно отнести группы в Application Access, ибо лучше делать так, чтобы прописанные там группы давали только право логина, без просмотра конкретных. Хороший пример такой группы - jira-bulk-editors. Bulk editing - удобная, но в неумелых руках опасная функция, к тому же настраиваемая в Global Permissions. Так что лучше выделить пользователей имеющих такое право в отдельную группу.
- Удобная вещь - назначение на группу, но для этого нужно поле Group Picker (о нем ниже). В Jira из коробки нет этого функционала, так как исповедуется в целом логичная мысль, что исполнитель должен быть конкретен и он один.
- Следует быть осторожными при указании групп в схемах нотификаций, особенно с большими группами, типа jira-*-users. Во-первых, массовые рассылки есть спам, во-вторых Jira формирует и отправляет письма последовательно, то есть при большой группе будет создана дополнительная не очень и нужна нагрузка. Для разовой массовой рассылки можно использовать функцию Send Email в административном интерфейсе.
Project role
Описание
Проектные роли - гибкий и легкий способ привязки пользователей и групп к определенным проектам. Роли определяются администраторами Jira на уровне всей системы.
Использование в системе
Роли используются в Permission schemes, Notidication schemes, Issue Security levels, а также в Conditions процессов. Различные плагины расширяют использование ролей. Кроме того, роли можно указывать в настройках видимости комментариев issues, а также использовать для предоставления доступа к сохраненным фильтрам и дашбордам.
Проектные роли чем-то похожи на группы, однако главное различие в том, что участие в группе глобально, а нахождение в роли зависит от проекта к проекту. Кроме того, управлять составом групп могут только администраторы Jira, а проектные роли могут быть могут назначаться администраторами проекта (т.е. имеющими разрешение Administer Projects).
Как правильно готовить
- Основное правило - не путать роли с группами и не плодить их. Отличить очень просто - роль в Jira является процессной ролью, а группа - скорее просто множеством пользователей.
- Использовать вовсю разделение между администраторами Jira и проектными администраторами, это позволяет всем сэкономить время, а руководителям проекта гибко управлять участниками ролей.
- Использовать функцию "Default Members" для проектных ролей. В таком случае, при создании нового проекта в роль будет автоматически добавлять выбранная группа. Это удобно, когда есть постоянное требование доступа к проекту определенных пользователей - разработчиков (если вся команда делает много проектов), очень часто это некий внутренний аудит и ИБ.
Project lead
Описание
По факту Project Lead является тоже проектной ролью, но в системе он выделен отдельно и по сути является атрибутом проекта. Такое выделение несет еще и организационную нагрузку - в списке проектов в системе видно кто является Project Lead (читай - кому нужно эскалировать вопросы).
Использование в системе
Для каждого проекта Project Lead устанавливается отдельно и этот атрибут проекта является обязательным. По умолчанию данную роль занимает создатель проекта. Project Lead может использоваться как и все прочие роли, а кроме того в качестве Default Assignee проекта или компонента. Использование в схемах и процессах аналогично прочим ролям.
Как правильно готовить
Однозначных рекомендаций вроде бы и нет, но следуя здравому смыслу на данную роль хорошо бы назначать фактического менеджера проекта. Кроме того, удобно дать данной роли право Administer Projects в Permission scheme.
Default assignee
Описание
Название говорит само за себя - исполнитель по умолчанию.
Использование в системе
Используется в основном в 2-х местах: проектах и компонентах (и в одной пост-функции). Для того, чтобы задачи назначались на Default assignee, требуется выполнение нескольких условий:
- При создании issue в поле Assignee должно стоять значение Automatic (это происходит по умолчанию, если нет никаких кастомизаций)
- Для проекта в данном поле должен быть указан Project Lead. Это сработает, если нет компонентов или для компонентов не указаны другие Default Assignee.
- Если компоненты указаны и для них проставлен Default Assignee, то тогда issue будет назначен на данного персонажа.
Как правильно готовить
- Заполняйте поле это поле для проекта, если вам важно, чтобы создаваемые задачи не пропадали втуне. Часто бывает так, что пользователь заходит в проект, создает задачу, но не знает на кого назначить. Как раз при таком сценарии и полезен данный атрибут.
- Если вы используете компоненты (компонент может обозначить не только часть ПО, но и в целом любую структурную часть чего-либо), то указание Default Assignee позволит автоматически маршрутизировать issue. Это экономит время.
Component lead
Описание
Подразумевается, что в проекте по разработке программного продукта могут выделяться отдельные компоненты/модули (frontend, backend, database, etc.) и у каждого компонента может быть свой lead, руководитель.
Использование в системе
Список компонентов является уникальным для каждого проекта. Соответственно, для каждого компонента опционально может быть указан component lead. Для того чтобы issue с данным компонентом был назначен на него, нужно в поле Default Assignee компонента указать Component Lead. Есть небольшая хитрость, связанная с тем, что для issue можно указать больше одного компонента. В таком случае, issue будет назначен на Component Lead того компонента, чье имя идет первым по алфавиту.
Как правильно готовить
- Основная проблема с компонентами - это правильное их выделение, что скорее относится не к Jira как таковой, а в целом к архитектуре проекта и к организации работ на проекте. Так что - классифицировать компоненты и назначить ответственных по ним - первое дело.
- Так как Jira часто используется не только для проектов по разработке, то компонент может представлять собой нечто совершенно другое. Из опыта - компонент представлял собой ЦФО (центр финансовой ответственности) и использовался при согласовании заявок на оплату.
Reporter
Описание
Все просто - это создатель issue.
Использование в системе
Данная роль является атрибутом issue. Хитрость в том, что пользователь в проекте, имеющий разрешение Modify Reporter может изменить значение данного поля. По умолчанию это поле является обязательным, то есть не может быть пустым, однако есть вот такой возможный сценарий - пользователь, стоящий в поле Reporter, был удален (не деактивирован, а именно удален). В данном случае в этом поле будет стоять значение Anonymous. Кроме того, данная роль активно используется в валидаторах, условиях и пост-функциях процессов, а также Permission, Notification, Issue Security schemes.
Как правильно готовить
- Часто бывает удобно при смене статусов issue делать переназначение - делайте это с помощью пост-функций. Такая функциональность нужна, например, при общении клиента и сотрудника поддержки.
- Другая часто встречающаяся задача - "завести issue за кого-то, но чтобы было видно, кто создал". Такой сценарий реализуется путем создания кастомного поля типа User Picker (single user), в котором и указывается нужный пользователь.
- ВАЖНО: не указывайте Reporter для разрешения Browse Projects. При текущей реализации это открывает доступ всем пользователям. Используйте Issue Security Scheme.
Assignee
Описание
Проще некуда - Исполнитель issue собственной персоной.
Использование в системе
Данная роль также является атрибутом issue. Чтобы быть исполнителем, нужно иметь разрешение Assignable User. Кроме того, данное поле может иметь значение Unassigned, но это должно быть включено в глобальных настройках системы. Данный атрибут неразрывно связан с Default Assignee и Component Lead - именно из данных сущностей могут браться значения при назначении issue в автоматическом режиме. Еще важный момент - пользователя, являющегося исполнителем нельзя удалить - система будет ругаться. Для удаления (помним, что это не лучший вариант?) сначала нужно переназначить issue на другого исполнителя.
Как правильно готовить
- Имхо, правило хорошего тона - бесхозных задач быть не должно, иначе задача просто "булькнет" в болото. Так что - надо стараться, чтобы задачи всегда назначались на кого-то.
- Как и для Reporter, тоже есть ВАЖНО: не указывайте Reporter для разрешения Browse Projects. При текущей реализации это открывает доступ всем пользователям. Используйте Issue Security Scheme.
Watcher
Описание
Очень интересная сущность, представленная в GUI счетчиком 
. Наблюдатель - это пользователь получающий уведомления о событиях с issue (так по умолчанию, если все настроено). Наблюдателем может быть каждый.
Использование в системе
Наблюдатель является атрибутом issue, по факту является некой коллекцией пользователей. Для того, чтобы управлять наблюдателями для issue, пользователь должен иметь разрешение Manage Watchers. Кроме того, если сконфигурировано глобально в системе и не переопределено пользователем в своем профиле, то наблюдателем автоматически становится Reporter и пользователь, написавший хотя бы один комментарий к issue. Важно понимать, что Наблюдатель никак не относится с разрешениями, назначение пользователя наблюдателем никак не влияет на его права.
Как правильно готовить
- Используйте по назначению - для уведомления пользователей о событиях с issue.
- Очень у многих есть желание при назначении наблюдателей давать им права и т.п. Теоретически это можно сделать с помощью ScripRunner и его функционала Script Listeners.
Custom field - User Picker (single user), User Picker (multiple users)
Описание
Особый тип кастомного поля, позволяющий выбирать одного или более пользователей в системе.
Использование в системе
По умолчанию в системе не используется.
Как правильно готовить
- Часто поле типа User Picker (single user) удобно использовать для назначения issue. Например, код разработан и нужно отправить в тестирование. Делаем кастомное поле QA, добавляем пост-функцию, назначающую issue на пользователя из данного поля и вуаля.
- Поле типа User Picker (multiple users) удобно использовать для гранулированного доступа к issue. Например, нужно иметь возможность динамически менять список сотрудников, имеющих доступ к issue. Для этого в Issue Security Scheme проекта (она должна быть присвоена проекту) в нужном security level добавляем ранее созданное поле данного типа, назовем его Executors. Кидаем данное поле на экран/-ы issue и готово.
Custom field - Group Picker (single group), Group Picker (multiple groups)
Описание
Особый тип кастомного поля, позволяющий выбирать одну или более групп в системе.
Использование в системе
По умолчанию в системе не используется.
Как правильно готовить
- Jira не поддерживает назначение на группы из коробки, я писал об этом выше. Но с помощью данного поля и настройки уведомлений + фильтров можно сделать некое подобие. Конечно, есть и плагины для решения данной задачи, но с ними нужно быть осторожными.
- По аналогии с User Picker (multiple users) можно использовать для предоставления доступа.
Plugin roles
Описание
Многие плагины добавляют свои роли в список ролей Jira, а также имеют в своем функционале роли, которые никак не пересекаются с системой. Пример - Team Lead в Tempo Timesheets, роль существующая только внутри плагина.
Использование в системе
Все очень индивидуально и зависит от плагина.
Как правильно готовить
Опять-таки - все индивидуально.
Заключение
Итак, мы попробовали разобраться - что же внутри у Jira с точки зрения банальной социологии. Надеюсь, данная статья помогла немного развеять туман.
Was this helpful?
Thanks!
Anna Zekunova
4 comments