Я хочу поделиться с вами моим опытом по настройке системы регистрации и обработки заявок Atlassian JIRA, совместно с Atlassian Confluence в качестве системы тех. поддержки пользователей. Что пишут Atlassian по поводу этого можно почитать тут: http://confluence.atlassian.com/display/JIRA/JIRA+as+a+Support+System
Есть несколько концепций организации тех. поддержки. Первая из них – это настройка отдельного проекта для каждого клиента. Но эта концепция не рациональна в связи с тем, что сотрудники тех. поддержки не видят общей картины и при большом количестве клиентов возникает переизбыток проектов. Поэтому я расскажу вам о другой концепции – с одним проектом Service Desk для всех клиентов с настроенными областями видимости.
Начнём с настройки Permission Scheme для проекта, то есть доступы. Почитать, как это делается, можно тут: http://confluence.atlassian.com/display/JIRA/Managing+Project+Permissions Я думаю, довольно очевидно, что пользователь должен иметь доступы на просмотр проекта, создание там запросов, закрытие их, прикрепление файлов, оставление комментов.
Теперь настроим области видимости. В JIRA есть такое понятие, как Security level. Запросы, находящиеся в каком-то уровне доступа, видны ТОЛЬКО тем, кому разрешено видеть этот уровень доступа. Даже администраторы не увидят запросы, которым приписан чужой уровень доступа. Тут тоже есть 2 варианта, выбор варианта зависит от ваших потребностей. Как создавать и настраивать уровни доступа: http://confluence.atlassian.com/display/JIRA/Configuring+Issue+Level+Security
1 вариант: создаём уровень доступа Private, куда допускаем сотрудников тех. поддержки и Reporter’а задачи. Делаем этот уровень дефолтным. В Permission Scheme должно быть отключено выставление Security Level’а пользователем (ну, или включено, но тогда он сможет оставлять запросы, видимые всем пользователям, что тоже нужно в некоторых ситуациях). Итак, любой простой пользователь будет видеть только свои запросы, а сотрудники тех. поддержи – все запросы, что нам и требуется.
2 вариант: данный вариант предусматривает множество уровней безопасности для групп клиентов, это требуется в случае, если наши клиенты – компании с множеством сотрудников, и запросы должны быть общими для всех сотрудников одной компании. Соответственно, для начала нам надо создать соответствующие уровни доступа для каждого клиента. Затем нам понадобится плагин We engineer ( https://plugins.atlassian.com/plugin/details/22874 ). Он позволяет выставлять Security Level в зависимости от Project Role как пост-функция Workflow (жизненного цикла заявки, почитать о нём и его настройке можно тут: http://confluence.atlassian.com/display/JIRA/Configuring+Workflow ). Создаём дополнительные Project Role, соответствующие клиенту (Users, Groups & Roles -> Project Role Browser), в проекте Service desk задаём эту роль соотвествующей группе пользователей. Затем идём в настройки нашего Workflow, переходим на первую Transition – Create и добавляем пост функции, как это указано в документации к плагину. (Важное замечание: когда мы создаём эти функции на первом шаге (creation), необходимо ставить их первыми. На других шагах – последними.) Таким образом, при создании заявки уровень безопасности будет назначаться автоматом.
О настройке Workflow я говорить не буду, так как всё, что нужно знать, описано тут: http://confluence.atlassian.com/display/JIRA/Configuring+Workflow
Ещё надо сказать о способе передачи заявок разработчикам. Для этого удобно использовать плагин Clone Plus ( https://plugins.atlassian.com/plugin/details/44043 ). Просто ставим его и появляется кнопочка Clone++, которая позволяет склонировать запрос со всеми комментариями и аттачами в другой проект. Клон и оригинал будут связаны ссылкой.
Вообще, есть довольно много плагинов, помогающих использовать JIRA в качестве системы поддержи. Их можно найти тут: https://plugins.atlassian.com/search/category/21338.
Теперь о Confluence.
Основные функции можно почитать тут: http://confluence.atlassian.com/display/DOC/Confluence+Documentation+Home
Помимо того, что в этой системе можно хранить документацию с разными уровнями доступа, есть ещё одна полезная особенность: если настроить в Confluence синхронизацию с системой JIRA, можно дать некоторым пользователям «администраторские права» в своей группе, таким образом, что он может добавлять пользователей в свои группы и удалять их из неё. То есть, компания сама может управлять своими сотрудниками и их доступами в системе. При этом можно открыть регистрацию, но запретить свежезарегестрированным пользователям делать что-либо, пока их не зарегистрировали админы. Для этого нужен плагин Custom Space User Management Plugin ( https://plugins.atlassian.com/plugin/details/133?versionId=373044 ). Создаём для каждого клиента Space «песочницу», в которой он будет полный хозяин, создаём группы с префиксом, являющимся ключом это «песочницы» и даём этим группам соответствующие доступы в JIRA и Confluence.
Вот и всё пока что, если у кого-то появится интерес, могу углубиться в некоторые моменты.
Есть несколько концепций организации тех. поддержки. Первая из них – это настройка отдельного проекта для каждого клиента. Но эта концепция не рациональна в связи с тем, что сотрудники тех. поддержки не видят общей картины и при большом количестве клиентов возникает переизбыток проектов. Поэтому я расскажу вам о другой концепции – с одним проектом Service Desk для всех клиентов с настроенными областями видимости.
Начнём с настройки Permission Scheme для проекта, то есть доступы. Почитать, как это делается, можно тут: http://confluence.atlassian.com/display/JIRA/Managing+Project+Permissions Я думаю, довольно очевидно, что пользователь должен иметь доступы на просмотр проекта, создание там запросов, закрытие их, прикрепление файлов, оставление комментов.
Теперь настроим области видимости. В JIRA есть такое понятие, как Security level. Запросы, находящиеся в каком-то уровне доступа, видны ТОЛЬКО тем, кому разрешено видеть этот уровень доступа. Даже администраторы не увидят запросы, которым приписан чужой уровень доступа. Тут тоже есть 2 варианта, выбор варианта зависит от ваших потребностей. Как создавать и настраивать уровни доступа: http://confluence.atlassian.com/display/JIRA/Configuring+Issue+Level+Security
1 вариант: создаём уровень доступа Private, куда допускаем сотрудников тех. поддержки и Reporter’а задачи. Делаем этот уровень дефолтным. В Permission Scheme должно быть отключено выставление Security Level’а пользователем (ну, или включено, но тогда он сможет оставлять запросы, видимые всем пользователям, что тоже нужно в некоторых ситуациях). Итак, любой простой пользователь будет видеть только свои запросы, а сотрудники тех. поддержи – все запросы, что нам и требуется.
2 вариант: данный вариант предусматривает множество уровней безопасности для групп клиентов, это требуется в случае, если наши клиенты – компании с множеством сотрудников, и запросы должны быть общими для всех сотрудников одной компании. Соответственно, для начала нам надо создать соответствующие уровни доступа для каждого клиента. Затем нам понадобится плагин We engineer ( https://plugins.atlassian.com/plugin/details/22874 ). Он позволяет выставлять Security Level в зависимости от Project Role как пост-функция Workflow (жизненного цикла заявки, почитать о нём и его настройке можно тут: http://confluence.atlassian.com/display/JIRA/Configuring+Workflow ). Создаём дополнительные Project Role, соответствующие клиенту (Users, Groups & Roles -> Project Role Browser), в проекте Service desk задаём эту роль соотвествующей группе пользователей. Затем идём в настройки нашего Workflow, переходим на первую Transition – Create и добавляем пост функции, как это указано в документации к плагину. (Важное замечание: когда мы создаём эти функции на первом шаге (creation), необходимо ставить их первыми. На других шагах – последними.) Таким образом, при создании заявки уровень безопасности будет назначаться автоматом.
О настройке Workflow я говорить не буду, так как всё, что нужно знать, описано тут: http://confluence.atlassian.com/display/JIRA/Configuring+Workflow
Ещё надо сказать о способе передачи заявок разработчикам. Для этого удобно использовать плагин Clone Plus ( https://plugins.atlassian.com/plugin/details/44043 ). Просто ставим его и появляется кнопочка Clone++, которая позволяет склонировать запрос со всеми комментариями и аттачами в другой проект. Клон и оригинал будут связаны ссылкой.
Вообще, есть довольно много плагинов, помогающих использовать JIRA в качестве системы поддержи. Их можно найти тут: https://plugins.atlassian.com/search/category/21338.
Теперь о Confluence.
Основные функции можно почитать тут: http://confluence.atlassian.com/display/DOC/Confluence+Documentation+Home
Помимо того, что в этой системе можно хранить документацию с разными уровнями доступа, есть ещё одна полезная особенность: если настроить в Confluence синхронизацию с системой JIRA, можно дать некоторым пользователям «администраторские права» в своей группе, таким образом, что он может добавлять пользователей в свои группы и удалять их из неё. То есть, компания сама может управлять своими сотрудниками и их доступами в системе. При этом можно открыть регистрацию, но запретить свежезарегестрированным пользователям делать что-либо, пока их не зарегистрировали админы. Для этого нужен плагин Custom Space User Management Plugin ( https://plugins.atlassian.com/plugin/details/133?versionId=373044 ). Создаём для каждого клиента Space «песочницу», в которой он будет полный хозяин, создаём группы с префиксом, являющимся ключом это «песочницы» и даём этим группам соответствующие доступы в JIRA и Confluence.
Вот и всё пока что, если у кого-то появится интерес, могу углубиться в некоторые моменты.
