Практическая социология в JIRA

Практическая социология в JIRA

Что, зачем и почему

В данной статье Anton Chemlev попробует разобраться кто есть кто в JIRA: пользователи, группы, роли и т.п. Тема достаточно сложная и многие пользователи/администраторы путаются. Цель статьи такова - после ознакомления с текстом у читателя должно сформироваться общее понимание устройства пользовательской, групповой и ролевой модели JIRA.

ВАЖНО: Мы говорим о версии Jira > 7.X.X, так именно в 7-ке появились изменения в пользовательской модели.

 

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

image.png

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

  • Описание
  • Использование в системе
  • Как правильно готовить

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 (сразу оговорюсь, что так можно делать, но не нужно - лучше не завязываться на конкретную личность, ибо люди имеют свойство увольняться, болеть и т.п.).

Как правильно готовить

  1. Придумать naming convention. Например, name.surname или что-то подобное. Если пользователи тянутся из LDAP, то тогда уже ничего не сделаешь. Но если нет - обязательно следовать naming convention, так как далее будет проще использовать имена в скриптах, например.
  2. Не удалять пользователя, если он уже работал в системе и создавал контент. Нужно просто его деактивировать. 
  3. Следить за активностью пользователей, особенно если у вас большая инсталляция, и не настроена интеграция с LDAP, при которой пользователи автоматически деактивируются при деактивации их в LDAP. Проще всего это делать раз в несколько месяцев, выгрузив из БД список пользователей с датами создания, обновления, последнего логина и деактивировав ненужных уже пользователей. Только учтите, что данные по последнему логину могут быть не совсем корректными, если пользователь при последнем логине поставил чек-бокс Remember me. В таком случае датой последнего логина будет являться как раз дата, когда он решил использовать Remember me. По умолчанию запоминается на 14 дней.
  4. Не быть жадиной и создать технического/-их пользователей для автоматического выполнения скриптов и интеграций.

Group

Описание

Тоже простая концепция - это объединение пользователей в некое множество по какому-либо признаку. Группы могут как создаваться локально, так и тянуться из LDAP, либо все вместе. 

Использование в системе

Использование также повсеместное, как и у User, использование в схемах и процессах тоже аналогичное. Но есть важное отличие: именно группе/-ам предоставляется Application Access, оно же - право логина в систему. Какая-либо из групп, указанных в Application Access может быть назначена default, пользователи будут попадать в эту группу при создании. По умолчанию это группа jira-core-users или jira-software-users, создаваемые системой наряду с группой jira-administrators. 

Как правильно готовить

  1. Naming convention. В случае с группами это становится еще более важным, так как в отличие от User редактировать имя группы нельзя - только создавать заново, переносить пользователей, прописывать в конфигурации проектов и т.п. Один из рекомендуемых форматов: jira-group-name. 
  2. Продумать группы каких типов у вас будут. Исходя из своего опыта могу предложить такую классификацию:
    • Группы-структурные подразделения. Практически всегда удобно, за исключением случаев, когда очень большая вложенность. 
    • Группы-проектные команды. Кроссфункциональные команды, работающие над проектом.
    • Функциональные группы. Например, деление на группы аналитиков, разработчиков, тестировщиков и т.п. Немного напоминает первый пункт, но все зависит от сложности орг.структуры и принятых правил работы.
    • Группы-разрешения (коряво звучит, но пусть так). Сюда можно отнести группы в Application Access, ибо лучше делать так, чтобы прописанные там группы давали только право логина, без просмотра конкретных. Хороший пример такой группы - jira-bulk-editors. Bulk editing - удобная, но в неумелых руках опасная функция, к тому же настраиваемая в Global Permissions. Так что лучше выделить пользователей имеющих такое право в отдельную группу.
  3. Удобная вещь - назначение на группу, но для этого нужно поле Group Picker (о нем ниже). В Jira из коробки нет этого функционала, так как исповедуется в целом логичная мысль, что исполнитель должен быть конкретен и он один. 
  4. Следует быть осторожными при указании групп в схемах нотификаций, особенно с большими группами, типа jira-*-users. Во-первых, массовые рассылки есть спам, во-вторых Jira формирует и отправляет письма последовательно, то есть при большой группе будет создана дополнительная не очень и нужна нагрузка. Для разовой массовой рассылки можно использовать функцию Send Email в административном интерфейсе.

Project role

Описание

Проектные роли - гибкий и легкий способ привязки пользователей и групп к определенным проектам. Роли определяются администраторами Jira на уровне всей системы.

Использование в системе

Роли используются в Permission schemes, Notidication schemes, Issue Security levels, а также в Conditions процессов. Различные плагины расширяют использование ролей. Кроме того, роли можно указывать в настройках видимости комментариев issues, а также использовать для предоставления доступа к сохраненным фильтрам и дашбордам.

Проектные роли чем-то похожи на группы, однако главное различие в том, что участие в группе глобально, а нахождение в роли зависит от проекта к проекту. Кроме того, управлять составом групп могут только администраторы Jira, а проектные роли могут быть могут назначаться администраторами проекта (т.е. имеющими разрешение Administer Projects). 

Как правильно готовить

  1. Основное правило - не путать роли с группами и не плодить их. Отличить очень просто - роль в Jira является процессной ролью, а группа - скорее просто множеством пользователей. 
  2. Использовать вовсю разделение между администраторами Jira и проектными администраторами, это позволяет всем сэкономить время, а руководителям проекта гибко управлять участниками ролей.
  3. Использовать функцию "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 будет назначен на данного персонажа.

Как правильно готовить

  1. Заполняйте поле это поле для проекта, если вам важно, чтобы создаваемые задачи не пропадали втуне. Часто бывает так, что пользователь заходит в проект, создает задачу, но не знает на кого назначить. Как раз при таком сценарии и полезен данный атрибут.
  2. Если вы используете компоненты (компонент может обозначить не только часть ПО, но и в целом любую структурную часть чего-либо), то указание Default Assignee позволит автоматически маршрутизировать issue. Это экономит время.

Component lead

Описание

Подразумевается, что в проекте по разработке программного продукта могут выделяться отдельные компоненты/модули (frontend, backend, database, etc.) и у каждого компонента может быть свой lead, руководитель.

Использование в системе

Список компонентов является уникальным для каждого проекта. Соответственно, для каждого компонента опционально может быть указан component lead. Для того чтобы issue с данным компонентом был назначен на него, нужно в поле Default Assignee компонента указать Component Lead. Есть небольшая хитрость, связанная с тем, что для issue можно указать больше одного компонента. В таком случае, issue будет назначен на Component Lead того компонента, чье имя идет первым по алфавиту.

Как правильно готовить

  1. Основная проблема с компонентами - это правильное их выделение, что скорее относится не к Jira как таковой, а в целом к архитектуре проекта и к организации работ на проекте. Так что - классифицировать компоненты и назначить ответственных по ним - первое дело.
  2. Так как Jira часто используется не только для проектов по разработке, то компонент может представлять собой нечто совершенно другое. Из опыта - компонент представлял собой ЦФО (центр финансовой ответственности) и использовался при согласовании заявок на оплату.

 

Reporter

Описание

Все просто - это создатель issue. 

Использование в системе

Данная роль является атрибутом issue. Хитрость в том, что пользователь в проекте, имеющий разрешение Modify Reporter может изменить значение данного поля. По умолчанию это поле является обязательным, то есть не может быть пустым, однако есть вот такой возможный сценарий - пользователь, стоящий в поле Reporter, был удален (не деактивирован, а именно удален). В данном случае в этом поле будет стоять значение Anonymous. Кроме того, данная роль активно используется в валидаторах, условиях и пост-функциях процессов, а также Permission, Notification, Issue Security schemes. 

Как правильно готовить

  1. Часто бывает удобно при смене статусов issue делать переназначение - делайте это с помощью пост-функций. Такая функциональность нужна, например, при общении клиента и сотрудника поддержки.
  2. Другая часто встречающаяся задача - "завести issue за кого-то, но чтобы было видно, кто создал". Такой сценарий реализуется путем создания кастомного поля типа User Picker (single user), в котором и указывается нужный пользователь.
  3. ВАЖНО: не указывайте Reporter для разрешения Browse Projects. При текущей реализации это открывает доступ всем пользователям. Используйте Issue Security Scheme.

 

Assignee

Описание

Проще некуда - Исполнитель issue собственной персоной.

Использование в системе

Данная роль также является атрибутом issue. Чтобы быть исполнителем, нужно иметь разрешение Assignable User. Кроме того, данное поле может иметь значение Unassigned, но это должно быть включено в глобальных настройках системы. Данный атрибут неразрывно связан с Default Assignee и Component Lead - именно из данных сущностей могут браться значения при назначении issue в автоматическом режиме. Еще важный момент - пользователя, являющегося исполнителем нельзя удалить - система будет ругаться. Для удаления (помним, что это не лучший вариант?) сначала нужно переназначить issue на другого исполнителя.

Как правильно готовить

  1. Имхо, правило хорошего тона - бесхозных задач быть не должно, иначе задача просто "булькнет" в болото. Так что - надо стараться, чтобы задачи всегда назначались на кого-то.
  2. Как и для Reporter, тоже есть ВАЖНО: не указывайте Reporter для разрешения Browse Projects. При текущей реализации это открывает доступ всем пользователям. Используйте Issue Security Scheme.

 

Watcher

Описание

Очень интересная сущность, представленная в GUI счетчиком (улыбка). Наблюдатель - это пользователь получающий уведомления о событиях с issue (так по умолчанию, если все настроено). Наблюдателем может быть каждый.

Использование в системе

Наблюдатель является атрибутом issue, по факту является некой коллекцией пользователей. Для того, чтобы управлять наблюдателями для issue, пользователь должен иметь разрешение Manage Watchers. Кроме того, если сконфигурировано глобально в системе и не переопределено пользователем в своем профиле, то наблюдателем автоматически становится Reporter и пользователь, написавший хотя бы один комментарий к issue. Важно понимать, что Наблюдатель никак не относится с разрешениями, назначение пользователя наблюдателем никак не влияет на его права.

Как правильно готовить

  1. Используйте по назначению - для уведомления пользователей о событиях с issue.
  2. Очень у многих есть желание при назначении наблюдателей давать им права и т.п. Теоретически это можно сделать с помощью ScripRunner и его функционала Script Listeners.

 

Custom field - User Picker (single user), User Picker (multiple users)

Описание

Особый тип кастомного поля, позволяющий выбирать одного или более пользователей в системе.

Использование в системе

По умолчанию в системе не используется.

Как правильно готовить

  1. Часто поле типа User Picker (single user) удобно использовать для назначения issue. Например, код разработан и нужно отправить в тестирование. Делаем кастомное поле QA, добавляем пост-функцию, назначающую issue на пользователя из данного поля и вуаля.
  2. Поле типа User Picker (multiple users) удобно использовать для гранулированного доступа к issue. Например, нужно иметь возможность динамически менять список сотрудников, имеющих доступ к issue. Для этого в Issue Security Scheme проекта (она должна быть присвоена проекту) в нужном security level добавляем ранее созданное поле данного типа, назовем его Executors. Кидаем данное поле на экран/-ы issue и готово. 

 

Custom field - Group Picker (single group), Group Picker (multiple groups)

Описание

Особый тип кастомного поля, позволяющий выбирать одну или более групп в системе.

Использование в системе

По умолчанию в системе не используется.

Как правильно готовить

  1. Jira не поддерживает назначение на группы из коробки, я писал об этом выше. Но с помощью данного поля и настройки уведомлений + фильтров можно сделать некое подобие. Конечно, есть и плагины для решения данной задачи, но с ними нужно быть осторожными.
  2. По аналогии с User Picker (multiple users) можно использовать для предоставления доступа.

 

Plugin roles

Описание

Многие плагины добавляют свои роли в список ролей Jira, а также имеют в своем функционале роли, которые никак не пересекаются с системой. Пример - Team Lead в Tempo Timesheets, роль существующая только внутри плагина.

Использование в системе

Все очень индивидуально и зависит от плагина.

Как правильно готовить

Опять-таки - все индивидуально. (улыбка)


Заключение

Итак, мы попробовали разобраться - что же внутри у Jira с точки зрения банальной социологии. Надеюсь, данная статья помогла немного развеять туман. 

2 comments

Аня, как артиклс писать?:)

Статьи пишут чемпионы. Их отбирают, чтобы небыло спама. Вот тут описано подробно что нужно, чтобы стать чемпионом.

Comment

Log in or Sign up to comment
Community showcase
Published Dec 03, 2018 in Agile

Marketplace Spotlight: Deviniti

 Hello Atlassian Community! Each month, we run a series of Spotlights to highlight Marketplace vendors and apps that our team thinks this Community would find valuable. In last month's S...

204 views 1 6
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you