Jira service desk инструкция на русском

Шаг 1. Создание и настройка проекта

Подробнее о шаблонах проектов в Jira Service Management

Подробнее о настройке центра поддержки

Подробнее о настройке центра поддержки и порталов

Подробнее о получении запросов по электронной почте

Шаг 2. Настройка типов запросов и очередей

Подробнее о группировании запросов клиентов по типам запросов

Подробнее о сортировке запросов клиентов для агентов с помощью очередей

Шаг 3. Добавление участников команды и клиентов в проект службы поддержки

Лицензирование

Jira Service Desk имеет специфическую схему лицензирования. Лицензируются так называемые агенты — пользователи Jira, которые по смыслу будут работать с запросами в Jira Service Desk. Ниже описаны основные роли:

Установка

Самый простой способ установить Jira Service Desk — перейти в раздел /plugins/servlet/applications/versions-licenses и установить JDS из раздела «ПРОЧИЕ ПРИЛОЖЕНИЯ JIRA»

Общие настройки Jira Service Desk

Общие настройки находятся в разделе Администрирование → Приложения. В разделах Конфигурация и Запросы по электронной почте можно настроить:

• внешний вид Service Desk портала и возможность его редактирования агентами;
• возможность публичной регистрации на портале;
• возможность агентам управлять организациями;
• возможность администраторам проектов создавать новые названия для метрик SLA;
• оповещение клиентов от Jira и Service Desk или только от Service Desk;
• обработка запросов по email (обработка кавычек, обработка html, добавление комментариев из email, создание клиентов из полей email-а to/cc)

Сценарий

Организация портала Service Desk (Help Desk) для сотрудников HR (все сотрудники HR имеют доступ в Jira). Также есть внешнее агенство (аутсорс), которое занимается поиском новых сотрудников. Сотрудники внешнего агенства не заведены как пользователи в Jira. HR и внешнее агенство используют для своей работы систему HRM.

Основные категории запросов — инцидент и запрос на обслуживание. Для простоты определим 3 типа запросов:

• Доступ в Jira Service Desk (запрос на обслуживание) — заявку создают сотрудники внешнего агенства;
• Доступ в HRM (запрос на обслуживание) — заявку создают сотрудники HR и сотрудники внешнего агенства; 
• Проблема в работе HRM (инцидент) — заявку создают сотрудники HR и сотрудники внешнего агенства; 

Настройка Jira Service Desk

Создадим проект с типом Service Desk (IT Service Desk)

При создании проекта с типом Basic создается 5 типов задач. Для целей из сценария оставим только два типа запросов: IT Help (инциденты), Service request with Approvals (сервисные запросы).

Типы запросов

Создадим две группы запросов «Запросы на обслуживание» и «Инциденты»

В группах создадим запросы на получение доступа (тип запроса «Service Request with Approvals«) и запрос о проблемах (тип запроса «IT Help«):

Через «Редактировать поля» добавим в каждом запросе дополнительные поля «Описание» и «Вложения». Поле «Описание» сделаем обязательным.

На вкладке «Состояния потока операций» (доступна на странице редактирования полей) переопределим статусы запросов.

Права доступа клиентов

Так как внешнее агенство сможет создавать запросы на доступ в Jira Service Desk по email, выставим соответствующую настройку

Настройки портала

Объявления на портале

Запросы по электронной почте

Прежде чем настроить возможность создавать запрос в Jira Service Desk по почте, вам необходимо иметь почтовую учетную запись. В нашем случае это hrm@itimizer.com.

На следующем этапе выберите какой тип запроса должен создаваться при отравке письма на адрес hrm@itimizer.com. Укажем запросы с типом «Доступ в Jira Service Desk».

Вы можете заметить, что не на любой тип запросов можно настроить почтовый канал. Это связано с тем, что для создания запросов по почте, в типе запроса должно быть только два обязательных поля «Тема» и «Описание».

В примере ниже, в типе запроса «Проблема в работе HRM», поле  «Вложения» указано как обязательное.

  

В итоге вы получите настроенный почтовый канал.

Уведомления клиентов

В уведомлении клиентов настроим общий стиль email оповещения через «Изменить шаблоны», который будет присутствовать во всех письмах Jira Service Desk независимо от статуса или перехода.

Через меню «Управлять языками» добавим поддержку русского языка в оповещениях.

Далее в качестве примера настроим формат оповещения клиента при создании запроса (действие «Редактировать» напротив «Запрос создан»).

Настройки уровня обслуживания

В настройках уровня обслуживания вы можете включить отправку формы оценки по решенному запросу. При решении запросов в Service Desk в письме дополнительно будет отправлена просьба поставить оценку по запросу. Выглядит это примерно так:

База знаний

Если у вас настроена связка между Jira и Confluence вы можете указать порталу Service Desk пространство в Confluence, по которому будет производится контекстный поиск через форму поиска Service Desk портала:

Теперь при вводе текста через форму поиска Service Desk портала вы будете получать ссылки на документы, содержащие данный текст. Это удобно использовать, например при создании типовых запросов, например, при проблеме с учетной записью email можно заранее подготовить инструкцию по самостоятельной проверке, после чего если клиент начнет вводить «проблема с email» появится подсказка на страницу в confluence. Правда стоит отметить, что поиск не всегда работает как нужно, особенно если это касается поиска по тексту на русском.

SLA

Основная вещь, которая отличает любой таск трекер от систем управления инцидентами и запросами на обслуживания — это возможность настройки SLA по различным типам запросов.

В качестве примера, настроим пользовательский SLA через «Создать показатель». Начало отсчета времени укажем с момента создания запроса, приостановку таймера укажем в статусах когда ожидается ответ пользователя и остановку таймера укажем при решении запроса. Время на выполнение запроса равно 72 часам (календарь по умолчанию). Для более деталного применения SLA вы можете использовать JQL-фильтр, ограничивающий типы задач, приоритет, автора и прочие параметры.

При этом в запросах с установленным SLA появится дополнительный tab SLA.

Автоматизация

Вы можете выбрать уже преднастроенные правила автоматизации или создать свои. Сделаем классическое правило переотрытия запроса после первого комментария клиента когда сам запрос уже переведен в Решен.

Очереди

Еще один важный функционал любой системы Service Desk это возможность организации очередей запросов. Добавим новую очередь через форму «Новая очередь».

Добавим новую очередь, в которой будут только запросы с типом «Получить доступ в Jira Service Desk» и по которым будует нарушен SLA.

Клиенты и организации

Добавлять новых клиентов и организации можно через форму «Заявители».

В целом это все основные базовые настройки Jira Service Desk. Приятного использования!

Настроим теперь работу JIRA SD через портал. Для начала зачем вообще нужен портал в JIRA. К примеру у Вас есть клиенты, которые создают обращения в техподдержку и которые хотят просматривать статус заведенных обращений. Портал в JIRA как раз и позволяет делать делать такое. Перейдем в Администрирование — Проекты — Техническая поддержка — Типы Запросов. Небольшое пояснение. Работа портала в JIRA основана на заведении запросов. В чем разница между запросами и задачами? В том, что интерфейс запросов в портале ограничен. Клиенты не могут видеть лишних меню и кнопок. Это достигается путем настройки бизнес-процесса. А также портал позволяет просматривать только запросы, которые завел клиент. Другие запросы он видеть не может. Все видят только специалисты, которые состоят в нужных группах.

И так создадим тип запроса Создать обращение, который будет у нас отображаться на портале. Укажем на основе какой задачи будет создавать запрос. Добавим описание по желанию. Подобным образом можно создать столько типов запросов сколько у вас создано задач.

Но сразу этот тип запроса на портале не появится. Дело в том, что когда мы очищали проект от настроек по умолчанию, мы также удалили все запросы и группы в которых они были. По умолчанию остается одна группа Скрыто от портала. Она то и не позволяет видеть этот тип запроса на портале. Создадим новую группу и назовем ее Для клиентов.

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

Должно в итоге выглядеть так:

С запросами разобрались. Предоставим теперь права нашим клиентам к порталу. Здесь важно иметь виду следующее. Если в JIRA SD только один проект, то можно оставит все как на скриншоте. Если же несколько проектов и Вы не хотите, что бы клиенты одного проекта видели типы запросов другого проекта на портале, то необходимо поставить переключатель в нужное меню.

Как только нажмем сохранить появится сообщение Разрешить регистрацию клиентов. Щелкаем на Включить.

Можно по другому добавить пользователя на портал. Пригласить его, указав его п/я и обязательно убрать галочку JIRA Service Desk. Иначе у него будут права инженера в системе. И все ему будет видно.

Настроим внешний вид портала в Настройки портала. Можно указать другое  имя и описание. А также добавить логотип

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

Портал также позволяет автоматически заводить задачи на основании письма отправленного на определенный ящик. Этот ящик можно настроить в Запросы по электронной почте.

Но скорее всего у Вас как только вы щелкните на Добавить адрес электронной почты появится следующая ошибка.

Здесь нужно понять и иметь виду следующее. Задачи в JIRA SD и на основе них созданные запросы, которые отображаются на портале состоят из разных полей. Порой обязательных к заполнению. А канал электронной почты, по которому мы хотим чтобы задачи создавались автоматически не знает и не сможет заполнить все поля в запросе. Поэтому судя из описания ошибки нужен такой тип запроса, в котором будет только два поля Тема (заголовок письма) и Описание (тело письма). Так как раннее созданный запрос Создать обращение имеет помимо полей Тема и Описание также поле Контур, которое обязательно к заполнению, мы создадим отдельную задачу, в котором будет только поле Тема и Описание. Назовем задачу и запрос Прочая Задача. Создайте его самостоятельно на основе предыдущих инструкция. Должно будет выглядеть примерно так.

Щелкнем на Редактировать поля и мы увидим, что поле Описание отсутствует, хотя мы его добавляли в монитор. Поэтому добавим его в запрос вручную через Добавить поле.

По желанию можно его сделать обязательным к заполнению

Также это поле можно сделать обязательным через Конфигурацию полей в Администрирование — Задачи — Поля. Щелкаем на меню Настроить столбца Действие соответствующей Конфигурации полей задачи. Находим нужное поле и щелкаем на Обязательно.

Теперь заново переходим в Администрирование — Проекты — Техническая поддержка — Запросы по электронной почте и щелкаем опять на Добавить адрес электронной почты. Указываем соответствующего провайдера и заполняем все поля. Затем щелкаем на Следующий.

Выбираем Тип запроса Прочая задача или свою, которую Вы создадите. И щелкаем на Выполнено. Через некоторое время на подключенный п/я придет сообщение что канал создан.

Если мы снова перейдем в  Администрирование — Проекты — Техническая поддержка — Типы запросов, то увидим, что запрос Прочая задача изменился.

Теперь попробуем отправить на этот п/я любое сообщение и через некоторое время мы увидим в очереди проекта Техническая поддержка Все открытые запросы новый запрос созданный посредством отправки письма на прикрученный ранее ящик.

Пост по настройке портала завершен

Добро пожаловать в JIRA Service Desk Server! В этом обзоре мы рассмотрим все, что вам нужно знать, чтобы интегрироваться с JIRA Service Desk Server. Это включает в себя фреймворк P2 для создания надстроек, а также функции и сервисы JIRA Service Desk, которые можно использовать при интеграции с JIRA Service Desk.

Привет мир

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

Что такое JIRA Service Desk?

Служба JIRA Service Desk в основном используется в качестве сервисного решения, от управления активами до DevOps. В разнообразных ИТ-командах используется JIRA Service Desk, включая группы поддержки, оперативные группы и многое другое. С более чем 15 000 из этих команд, использующих JIRA Service Desk, есть много возможностей для его расширения. Входите и начинайте!

Если вы ранее не использовали JIRA Service Desk, ознакомьтесь с обзором продукта для получения дополнительной информации.

Создание надстроек для JIRA Service Desk Server

Если вы хотите создать надстройку для JIRA Service Desk Server, вы должны использовать платформу разработки Atlassian, которая включает фрейворк Plugins2. Надстройки используются для расширения функциональности JIRA Service Desk, которая может быть интеграцией с другим существующим сервисом, новыми функциями для JIRA Service Desk или даже новым продуктом, который работает в JIRA Service Desk.

Основной поток разработки для создания надстройки JIRA Service Desk с использованием Atlassian SDK:

1. Создайте свой дополнительный проект, как и любое другое дополнение JIRA, например, с помощью команды SDK atlas-create-jira-plugin. Эта команда создает дополнительные файлы проекта и скелетный код.

1. Когда вы готовы к созданию и тестированию своего дополнения, запустите команду atlas-package из корневого каталога проекта. Эта команда создает пакетный JAR-файл, который вы можете установить в JIRA (в подкаталог target)

1. Настройте AMPS для запуска JIRA с установленной службой JIRA Service Desk. Если вы еще этого не делали, см. раздел Настройка AMPS для запуска JIRA Core с установленными дополнительными приложениями.
2. Запустите JIRA. Для ранней разработки и тестирования вы можете использовать экземпляр разработки, который SDK предоставляет вам при запуске следующей команды (установите версию до 7.0.0 или новее): atlas-run-standalone —product jira -version 7.0.0. 

1. Войдите в JIRA в качестве администратора, используя комбинацию имени пользователя и пароля по умолчанию admin / admin.

1. Установите надстройку, созданную на шаге 2, с помощью команды atlas-package. Вы можете сделать это двумя способами:
   1. Перейдите в Консоль администрирования и откройте страницу «Управление надстройками». На странице нажмите Загрузить надстройку и выберите файл JAR, созданный для вас командой atlas-package. Вы найдете JAR-файл в целевом каталоге вашего дома проекта после запуска atlas-package.
   2. Используя инструменты командной строки SDK: используя терминал, перейдите в домашний каталог проекта и просто запустите плагин atlas-install-plugin (после того, как он упаковал ваш дополнительный JAR с помощью команды SDK atlas-package). Эта команда просто загрузит ваше дополнение в UPM (и может значительно сократить ваш поток разработки).
2. Теперь вы должны увидеть свою надстройку на странице JIRA «Управление надстройками» в качестве установленного плагина. Каждый раз, когда вы меняете свой код надстройки или ресурсы, перезагрузите вашу надстройку повторяя шаг # 6 выше.

Если вы еще не создали надстройку, ознакомьтесь с руководством по началу работы. Это руководство поможет вам узнать, как настроить среду разработки и создать надстройку JIRA Server.

Разработка с помощью плагинов2

Если вы создаете надстройку с помощью Plugins2, вам также нужно будет понять ряд ключевых процессов разработки:

• Внедрение безопасности: внедрение безопасности является важной частью интеграции с JIRA. Подробнее об аутентификации и авторизации для JIRA Server см. в Обзор безопасности.
• Перечисление вашей надстройки на Atlassian Marketplace и внедрение лицензирования: список вашей надстройки на Atlassian Marketplaces и лицензирование необходимы, если вы хотите сделать свою надстройку доступной для общественности. Дополнительную информацию см. в Документация Marketplace.
• Проектирование вашей надстройки: поскольку надстройки Plugins2 могут вставлять контент непосредственно в приложение Atlassian host, крайне важно, чтобы надстройки были визуально совместимы с дизайном приложения Atlassian. Наши дизайнеры и разработчики создали ряд ресурсов, которые помогут вам в этом:
  • Atlassian Design Guidelines — наши руководящие принципы проектирования определяют основные взаимодействия с приложениями Atlassian.
  • Atlassian User Interface (AUI) — AUI — это библиотека многократно используемых внешних компонентов интерфейса.

Создание блоков для интеграции с сервером Service Desk JIRA

Три основных компонента интеграции с JIRA Service Desk — это API, веб-узлы и модули.

API-интерфейс JIRA Service Desk Server

API-интерфейсы JIRA Service Desk Server позволяют вашей интеграции взаимодействовать с JIRA Service Desk Server. Например, используя REST API, вы можете получить запросы очереди для отображения в своем надстройке или создавать запросы из телефонных звонков. Для большинства других интеграций вы должны использовать REST API. API Java следует использовать только в том случае, если вы создаете надстройку Plugins2.

• API-интерфейс REST API-службы JIRA Service Desk (последняя версия)
• JIRA Service Desk Server Java API (последняя версия)

Примечание. Служба JIRA Service Desk построена на платформе JIRA, поэтому вы можете использовать API-интерфейс REST API JIRA и API-интерфейс Java-платформы JIRA для взаимодействия с JIRA Service Desk Server.

Webhooks и правила автоматизации

Надстройки и приложения могут реагировать на условия / события в JIRA Service Desk с помощью правил автоматизации. Вы можете реализовать «действие автоматизации», которое выполняет действия в удаленной системе как часть правила автоматизации. Также можно настроить правило автоматизации для запуска веб-узлов, которые уведомляют ваше дополнение или приложение. Для получения дополнительной информации см. Веб-ссылки JIRA Service Desk.

Модули JIRA Service Desk

Модуль — это просто элемент пользовательского интерфейса, например вкладка или меню. Модули пользовательского интерфейса Service Desk JIRA позволяют надстройкам взаимодействовать с пользовательским интерфейсом JIRA Service Desk. Например, ваш надстройку может использовать модуль пользовательского интерфейса JIRA Service Desk для добавления панели в верхнюю часть клиентских порталов. Дополнительные сведения см. в разделе О модулях JIRA.

Сервер  JIRA Service Desk и платформа JIRA

JIRA Service Desk — это приложение, созданное на платформе JIRA. Платформа JIRA предоставляет набор базовых функциональных возможностей, которые распределяются между всеми приложениями JIRA, такими как задачи, рабочие процессы, поиск, электронная почта и т. д. Приложение JIRA является расширением платформы JIRA, которая обеспечивает определенную функциональность. Например, JIRA Service Desk добавляет порталы запросов клиентов, очереди поддержки, SLA, базу знаний и автоматизацию.

Это означает, что, когда вы разрабатываете JIRA Service Desk, вы фактически интегрируетесь с приложением JIRA Service Desk, а также с платформой JIRA. Приложение JIRA Service Desk и платформа JIRA имеют свои собственные API REST, события веб-хостинга и веб-фрагменты.

 Прочтите документацию на платформе JIRA Server для получения дополнительной информации.

Ищете вдохновение?

Если вы ищете идеи по созданию следующей интеграции JIRA Service Desk Server, это могут привести к следующим примерам использования и примерам.

Вот несколько распространенных случаев использования JIRA Service Desk:

• Support helpdesk: простой способ предоставить поддержку любому в организации с ИТ-запросами, такими как запросы на оборудование (ноутбук) или программное обеспечение.
• ITSM / ITIL: более продвинутые ИТ-команды хотят использовать сервисное решение для поддержки процессов ITSM и ITIL, включая управление инцидентами, проблемами и изменениями.
• Управление активами: ИТ-команды хотят открывать, контролировать, отслеживать и отслеживать ключевые ИТ-активы, такие как оборудование и серверы.
• DevOps: разработчики, операторы и ИТ-команды могут использовать JIRA Service Desk для совместной работы и решения проблем быстрее.
• Бизнес-команды: финансовые и HR-команды могут использовать JIRA Service Desk для сбора запросов от любого лица в организации.

Вот несколько примеров того, что можно построить поверх JIRA Service Desk:

• Настройка клиентского портала: JIRA Service Desk предоставляет интуитивно понятный клиентский портал, который позволяет нетехническим конечным пользователям взаимодействовать с сервисными группами, такими как ИТ и поддержка. Расширяя это, вы можете создать полностью адаптированный интерфейс для портала клиента, который соответствует брендингу вашей компании.
• Собирайте запросы за пределами службы поддержки JIRA: создавайте функциональные возможности для создания запросов от имени клиентов различными способами. Например, интегрируйте его в раздел поддержки вашего веб-сайта или получите меню помощи в мобильном приложении или подключите оповещения к инструменту системного мониторинга для создания инцидентов в JIRA Service Desk.
• Интеграция SLA: JIRA Service Desk вводит понятие соглашений об уровне обслуживания (SLA), позволяя командам точно измерять и устанавливать цели на основе временных показателей, например. время для назначения, время ответа, время до разрешения. С помощью REST API JIRA Service Desk вы можете получить подробную информацию об SLA и создать свои собственные отчеты.
• Интеграция телефонии: создание запросов на основе входящих голосовых вызовов путем интеграции вашей телефонной системы с JIRA Service Desk через API REST.
• Информация о дополнительном запросе: добавьте информацию об активах, клиенте или другой соответствующей информации в запросы, чтобы облегчить агентам решение проблем и закрытие запросов.

Больше информации

• jira-servicedesk-development tag на форуме Atlassian Answers — Присоединяйтесь к обсуждению разработки JIRA Service Desk.

По материалам Atlassian JIRA  Server Developer Integrating with JIRA Service Desk

Время на прочтение
9 мин

Количество просмотров 33K

Всем привет!

Хочу вам кратко рассказать о продукте от Atlassian: JIRA Service Desk
Точнее, о некоторых хитростях, которые сильно улучшают удобство использования продукта, т.к. про сам плагин сейчас уже многие в курсе.

Для хитростей необходимо использовать скрипты в постфункциях, в данном случае это sil-скрипты плагина JJupin, и уметь написать и выполнить (в т.ч. из скрипта) sql-запросы к БД, где JIRA хранит свои данные. По использованию плагина кратко в другой статье: «Atlassian JIRA: настройка процесса обработки заявок с помощью плагина JJUPIN».

JIRA Service Desk

По названию вроде оно и так понятно, для чего этот плагин — для того, чтобы в JIRA реализовать функциональность службы Service Desk. Но, на мой взгляд, самое главное — это прием заявок от пользователей в более удобном и красивом дизайне, с использованием отдельного портала под конкретный проект. И неважно, службу сервисдеск вы хотите организовать или просто прием заявок в какой-то проект.

Если же выражаться точнее и шире, то плагин добавляет в JIRA следующую функциональность:

• сам пользовательский портал, где пользователи могут создавать заявки, видеть список уже поданных заявок с краткой информацией по ним и статусами;
• настройка пользовательского портала;
• возможность установки значений уровней SLA на заявки с указанием условий через jql-запрос;
• отчетность по указанным SLA;
• очереди заявок с указанием условий отбора через jql-запрос;
• возможность прикрутить Базу Знаний к порталу.

Использовать эту функциональность вы можете как хотите: в полной мере, для реализации приема и обработки заявок службой Service Desk, либо например только выставление уровней SLA, чтобы контролировать своевременность выполнения заявок, поданных обычными способами, либо будете использовать очереди заявок, либо просто удобство портала по приему заявок

По поводу лицензий на JSD есть тонкости: сейчас они требуются только на тех пользователей, кто будет обрабатывать заявки в проектах, в которых включен Service Desk (их называют агентами), без ограничения по количеству подающих заявки. Раньше было по количеству лицензий в JIRA и те и те.

С одной стороны, если у вас всего 2-3 человека обрабатывают заявки, поданные через портал, то это экономно. Но если у вас заявки обрабатывают много пользователей — ну например в режиме, когда все проекты подключены к JSD, принимаются заявки через портал, а обрабатывают их соответственно пользователи этих проектов/отделов, то здесь уже печаль: цена на количество агентов от 15 и выше быстро уходят в космос. Мы успели купить по старой схеме, поэтому проблем нет.

По моему мнению, у этого плагина не хватает еще одного режима работы и лицензирования: использование только в качестве портала для приема заявок, с количеством лицензий равному таковому в JIRA, и соответственно более гуманной ценой. Потому как у нас большинство проектов не используют ничего, кроме портала (ну кое-где используются sla, минимум). Оно конечно, можно и отдельный плагин с порталом, но это еще один портал, что не есть хорошо. Может кто напишет? Сам бы написал, да не умею я в этом всем, чего тут нужно

Итак, теперь про хитрости (про использование и настройку самого плагина я начал писать статью, но не закончил, т.к. очень много всего: если будет сильно требоваться кому-то, может и напишу, а пока без оного)

Многообразие полей информации

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

Это все хорошо, конечно: для поля «Размер» я для одного типа заявок напишу «Укажите размер диска», а для другого «Размер экрана», поле у меня будет одно, но никто не запутается при подаче заявки, что там должно быть (это простой пример для понимания.

Но проблема в том, что в конечном итоге таких очень уникальных полей для самой разной информации может быть не один десяток, а то и сотни. И даже если какие-то поля использовать для разных типов заявки, но для похожей информации, количество реальных полей в JIRA не сильно уменьшится. А теперь представьте себе бедного администратора, который должен завести эту кучу полей — причем делать это постоянно, т.к. проекты растут, добавляются и т.д. Не можете представить? Я тоже, лучше и не надо.

Но выход есть!

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

Решение

• Понимаем, какое максимальное количество и какого типа уникальных полей может быть одновременно на экране создания заявки (если что, потом добавим). Их будет десяток, ну чуть больше — сравните со списком всех уникальных полей;
• Добавляем эти поля в JIRA в виде типа UniversalFieldString01, UniversalFieldString02, UniversalFieldMemo01 и т.д.(названия можете дать свои, главное учесть это в скрипте);
• Добавляем все эти поля на экраны создания заявок в тех проектах, где они будут использоваться (помимо стандартных темы, описания и т.д., чтобы они у нас появились при создании заявки);
• При настройке экрана заявки на портале добавляем эти поля в необходимом количестве для этого типа заявки (строковых столько, текстовых столько и т.д.);
• Указываем этим полям те названия и комментарии, которые должны быть у этого типа заявки;
• Пишем скрипт, который вызываем при создании заявки, и который из этих полей и их введенных значений составляет единый текст в виде «имя поля: значение поля» на каждой строке (ну или как угодно) и добавляет этот текст в описание заявки;
• Отдыхаем.

Тонкости и проблемы

Для строковых, текстовых и прочих полей, в которых нет предварительно заполненной информации, проблем нет вообще
А вот для разных списков мы имеем проблемы: заполненное значение у поля может быть разным только в разрезе проектов (конфигурация поля), внутри проекта значение для всех типов заявок будет одинаковым. В этом случае, если в одном проекте в разных заявках используется несколько таких уникальных полей, то их придется делать именно такое количество: UniversalFieldListBox01, UniversalFieldListBox02 и т.д. Спасает то, что в других проектах их можно использовать без проблем со своими значениями.

Скрипт
Итак, создаем sil-скрипт указанный ниже и вызываем его при создании заявки (этот код можно поместить в отдельный модуль в качестве функции и использовать ее вызов из других скриптов, чтобы не писать под каждый проект)
У нас JIRA работает на MS SQL Server, sql в скрипте под него, если у вас другая БД, то возможно придется немного поменять синтаксис:

    string[] flist;
    string _portalid = 1; //ID портала Service Desk, его можно найти в таблице ".._VIEWPORT", указать соответствующий проекту
    string sqlq;
    integer qty;
    integer i;
    string s;
    string sf;
    string sv;

// Внимание!!! Найдите в БД таблицу, у которой название содержит "VIEWPORT" и замените в sql-запросе в наименовании всех таблиц значение "AO_54307E_" на то, которое будет у вас

// Пишем запрос, который по указанному ID портала выдает нам все наши универсальные поля в виде списка: название поля "UniversalField..." и название поля на экране

    sqlq = " select PFF.Field_ID, PFF.Label, F.CFName ";
    sqlq = sqlq + " FROM [Jira].[dbo].[AO_54307E_VIEWPORT] P ";
	sqlq = sqlq + " join [Jira].[dbo].[AO_54307E_VIEWPORTFORM] PF on PF.ViewPort_ID = P.ID ";
	sqlq = sqlq + " join [Jira].[dbo].[AO_54307E_VIEWPORTFIELD] PFF on PFF.Form_ID = PF.ID and field_ID like '%custo%' ";
	sqlq = sqlq + " join [Jira].[dbo].[customfield] f on 'customfield_' + cast(f.ID as varchar) = PFF.Field_ID and F.CFName like 'UniversalField%' "; // Здесь мы отбираем только нам нужные поля (UniversalField....)
    sqlq = sqlq + " where P.ID = " + _portalid;
    sqlq = sqlq + " and PF.[Key] = replace('" + customfield_12700 + "', '" + project + "/', '') "; // Вместо customfield_12700 пишем "customfield_" и далее ID поля с названием "Customer Request Type" (смотреть в таблице customfield), в это поле в заявку JIRA записывает название типа экрана при создании заявки, это нам нужно для считывания названий полей, указанных на портале в настройке именно этого экрана
    
    flist = sql("jiraDS", sqlq); // jiraDS - это источник данных (datasource) к БД JIRA, в документации к jjupin есть информация по его созданию

    qty = arraySize(flist);
    i = 0;
    s = "";

    while (qty > i){
        sv = getElement(flist,i); // Берем название поля
        sf = %sv%; // Получаем его значение в заявке
        if ((indexOf(getElement(flist,i+2), "UniversalFieldDate") >= 0)) // Если поле - дата, то форматируем значение поля (название поля даты "Universal..." пишем как завели у себя)
        {
            sf = formatDate(%sv%, "dd.MM.yyyy");
        }
        if (sf != "") // Если значение не пустое, пишем в общий результат в виде "Название поля на экране портала" + перенос строки + "Значение поля" + 2 переноса (для читабельности)
        {
            s = s + getElement(flist,i+1) + ": \n" + sf + "\n\n";
        }
           
        i = i + 3;
    };
    
    if (s != "") // Если у нас хоть что-то записалось в результат, то добавляем его в описание заявки, в данном случае в начале описания, можно в конце, кому как
    {   
        if (desc != "")
        {
            s = s + "========= \n\n";
        }
        desc = s + desc;
    }

Ура, все работает!

Выглядит результат примерно так (это поле «Описание» в заявке):

Название программы:
Антивирус Касперского

Служебная необходимость:
очень надо

Имя компьютера:
komp13

=========

Добрый день!
Коллеги, просьба установить на компьютер антивирус

Честно говоря, это решение нас просто спасло от катастрофы (ну точнее, администраторов).

Все на портал!

Нет, не совсем все работает: мы теперь не хотим, чтобы все, кто угодно, делали заявки прямо через JIRA — их надо отправить на портал, там все красиво, бело и пушисто. Но как это сделать? Пиши, не пиши — обязательно найдется тот, кто будет делать заявку через JIRA и заполнит все не так (точнее, вообще ничего не заполнит, т.к. там одни UniversalField и т.д.)
С другой стороны, себе любимым надо разрешить делать заявки и напрямую, т.к… ну вы понимаете.

Решение
Решаем все тем же sil-скриптом, все там же при создании заявки, но уже используем его в виде валидатора
Дополнительно надо завести некую роль (либо использовать существующую) в проекте, в которой будут те люди, которые имеют право создавать заявки из JIRA:

if (customfield_12700 != "") // Здесь опять же вместо customfield_12700 пишем "customfield_" и далее ID поля с названием "Customer Request Type" (смотреть в таблице customfield), в это поле в заявку JIRA записывает название типа экрана при создании заявки, это нам нужно для понимания, откуда создается заявка: если там есть значение, значит из портала
{
    return true;
}

// Если напрямую из JIRA, то проверяем, содержится ли пользователь в нашей роли, и если он там - все хорошо
if (isUserInRole(currentUser(),project, "Роль для создания заявок"))
{
    return true;
}

// А если не там, то сообщаем, куда ему пойти
string s;
s = "Создание заявок стало возможно только через портал Service Desk! Пожалуйста, перейдите по ссылке: http://.... (ссылку необходимо скопировать и открыть в браузере)";

return false, "", s;

Кое-что по мелочи

Давайте представим, что вам надо завести на портале пару десятков экранов, и все они в основном с одинаковыми полями
Да даже взять один-два новых экрана
Т.е. это… надцать раз добавить по 10 полей, прописать им всем названия, комментарии, выставить порядок и обязательность
Оно конечно, можно вручную их набить от начала и до конца — и мы это делали.

Но есть способ, достаточно ускоряющий этот процесс: запустить sql-запрос, который нам сделает всю черновую работу

Итак, мы сначала создаем нужное количество экранов — со своими названиями, группами и т.д., но в поля не идем
Затем берем один экран и настраиваем на нем все поля, которые у нас будут представлены во всех экранах
Далее нам нужны будут ID этого экрана-шаблона и ID всех остальных экранов, которые мы создали. ID можно увидеть в адресной строке браузера при редактировании полей конкретного экрана.
По очереди подставляем эти ID в скрипт и запускаем. Можно через тот же sql-запрос вытащить все ID экранов и выполнить скрипт поочередно, можно вообще дописать sql-запрос так, чтобы он все сам там делал — это уже неважно. Важен пример, как легко и просто можно оперировать настройками экранов и портала сервисдеска: мы для каждого экрана добавляем в таблицу полей те поля, которые есть в экране-шаблоне и нет в этом экране, и в том порядке, как они там расположены.
Нажмите F5 после запуска запроса — и вы увидите все эти поля прямо сейчас на экране
Далее вам останется донастроить мелочи

Скрипт
Синтаксис MS SQL, также не забываем, что название таблиц плагина у вас может начинаться не на «AO_54307E_», поэтому надо его поменять в запросе

declare @form_id int, @newform_id int
set @form_id = -- подставляем ID экрана-шаблона
set @newform_id = -- подставляем ID каждого экрана, куда надо скопировать поля

INSERT INTO [Jira].[dbo].[AO_54307E_VIEWPORTFIELD]
           ([DESCRIPTION]
           ,[DISPLAYED]
           ,[FIELD_ID]
           ,[FIELD_TYPE]
           ,[FORM_ID]
           ,[LABEL]
           ,[REQUIRED]
           ,[FIELD_ORDER])
select           
           [DESCRIPTION]
           ,[DISPLAYED]
           ,[FIELD_ID]
           ,[FIELD_TYPE]
           ,@newform_id
           ,[LABEL]
           ,[REQUIRED]
           ,[FIELD_ORDER]
from	AO_54307E_VIEWPORTFIELD f
where	FORM_ID = @form_id and not exists(select 1 from AO_54307E_VIEWPORTFIELD f2 where f2.FORM_ID = @newform_id and f2.FIELD_ID = f.FIELD_ID)

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

---

Ну вот теперь красота!
Ну не совсем правда — картинок нет.

Возможно я что-то забыл — потом дополню.
Вопросы приветствуются, советы тоже.

Рассказываем, как внедрить Jira Service Desk в проект на примере двух наших сервисов Арендоход и Debug Mail.

10 шагов для организации первой рабочей версии поддержки
— Сведения
— Люди
— Тема
— Типы запросов
— Запросы по электронной почте
— Автоматизация
— Права доступа клиентов
— Настройки портала
— Уведомления клиентов
— Виджет
Тестирование фич при интеграции JSD в сервис по API
Заключение

В статье вы найдете инструкцию — какие действия предпринять, чтобы внедрить первую и простую версию поддержки пользователей. Рассмотрим основные сущности в Настройках Jira Service Desk (далее JSD) и что с ними делать. Также расскажем про часть настроек при внедрении JSD по API.

Некоторые разделы в Настройках JSD мы не рассматриваем — они не обязательны к первичному заполнению. Большинство из них относятся к общим настройкам Jira по Типам тасков, Воркфлоу, Правам, Доступам и т.п.

10 шагов для организации первой рабочей версии поддержки

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

1. Сведения,
2. Люди,
3. Тема,
4. Типы запросов,
5. Запросы по электронной почте,
6. Автоматизация,
7. Права доступа клиентов,
8. Настройки портала,
9. Уведомления клиентов,
10. Виджет.

1. Сведения

1. Заполнить Имя. Например, “DebugMail Team”.
2. Заполнить Ключ — короткое, название, которое будет стоять в URL тикета. Например, “DT”.
3. URL сервиса.
4. Аватар. Мы добавили ту же картинку, которую используем в сервисе как фавикон.
5. Описание. Например, “DebugMail Support Team”.
6. Указываем Руководителя проекта.
7. Исполнитель по умолчанию. Рекомендуем указывать “Руководитель проекта”, чтобы не было ситуации, когда у нового запроса нет исполнителя.

2. Люди

Бесплатная версия JSD позволяет создать support team максимум из 3-х человек.

Сотрудников добавляют в 2 этапа:

1. Через админку Jira (Администратор Atlassian) в Настройках пользователей в разделе Группы.
2. Через раздел Люди в настройках проекта JSD с указанием Роли сотрудника.

Люди — это раздел, где перечислены все пользователи Service Desk — и ваши сотрудники, и клиенты поддержки. Здесь можно назначать роли и добавлять пользователей.

3. Тема

Это технический раздел и связан с настройками в самой Jira — тип задачи (Jira Issue Type), бизнес-процессы (Workflow), компоненты, экраны, права и др. Вы можете использовать уже настроенные по умолчанию сущности JSD или в админке Jira настроить их самостоятельно.

4. Типы запросов

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

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

В Типах запросов настраиваем 3 блока параметров: отображение для агента, форма создания запроса и статусы рабочего процесса.

4.1. Отображение для агента

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

4.2. Форма создания запроса

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

4.3. Статусы рабочего процесса

Здесь настраиваем то, как отображаются для клиента статусы по воркфлоу.

5. Запросы по электронной почте

Можно использовать предоставляемый JSD аккаунт или подключить собственный — клиентам будут приходить оповещения от указанной вами почты.

6. Автоматизация

Позволяет системно подойти к автоответам, движению тикетов по воркфлоу, созданию и распределению задач между сотрудниками и не только, т.е. автоматизировать любое рутинное действие support team.

7. Права доступа клиентов

Права доступа регламентируют то, как будет пользователь взаимодействовать с JSD — можно ли заходить на портал и приглашать/видеть других сотрудников и тикеты.

Здесь нужно настроить 3 сущности:

1. У кого будет Доступ к проекту support.
2. Общий доступ клиентов.
3. И по ссылке администраторы могут изменить Настройки доступа клиентов — у кого и по каким правилам будет доступ к порталу.

В зависимости от сервиса, где вы подключаете JSD, будут требоваться разные настройки. Например, в Debug Mail мы получаем запросы от любого пользователя. Арендоход — закрытый сервис, доступ к которому согласовывает руководство клиента, поэтому там клиентов могут добавлять только агенты или администраторы.

8. Настройки портала

Позволяют сконфигурировать портал JSD под корпоративные стандарты. Если открыть для клиентов возможность видеть портал, то нужно заполнить Информацию о проекте сервиса:

1. Название.
2. Текст приветствия (желательно, но не обязательно).
3. Добавить логотип.

9. Уведомления клиентов

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

9.1. Настроить шаблон

Шаблон формирует общий принцип по содержанию уведомлений и есть возможность использовать различные переменные и добавлять их в тему письма или в текст уведомления.

9.2. Настроить уведомления клиентов

Ориентируясь на воркфлоу technical support это могут быть, например, следующие уведомления:

1. Запрос создан.
2. Добавлен общедоступный комментарий.
3. Запрос решен.
4. Участник добавлен.

9.3. Особенности настройки по API

Если подключаете JSD по API, нужно с осторожностью относится к встроенным шаблонам из-за ограничения: все запросы будут поступать только по одному ID пользователя Jira.

10. Виджет

Позволяет индивидуализировать этот элемент на сайте под ваши требования.

10.1. Особенности настройки по API

Если вы подключаете JSD по API, то настройка виджета вам не понадобится. Этим будет заниматься ваш фронтенд-разработчик и кастомизировать внешний вид под сервис.

Для сервиса Арендоход мы внедрили JSD по API, т.к. каждый запрос в сервисе должен быть привязан к конкретной локации.

Основа сервиса — интерактивная карта с объектами и запрос пользователя должен сопровождаться точным адресом и/или координатами. Стандартный функционал Service Desk не позволяет этого сделать, а заставлять пользователей самостоятельно заполнять поле с адресом — мы не стали.

Поэтому реализовали следующей процесс: после нажатия на кнопку Добавить комментарий на панели меню, предоставляется возможность поставить pin на любую локацию карты, где тут же открывается окно ввода данных Комментарий.

Тестирование фич при интеграции JSD в сервис по API

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

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

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

Заключение

Отталкиваясь от принципа запуска минимально жизнеспособного продукта (MVP), не стоит гнаться на начальном этапе за идеальной настройкой customer support service.

Настройте Jira Service Desk по 10 описанным шагам, получите фидбэк от пользователей и доработайте настройки.

Если остались вопросы — напишите нам.