Assets Cloud: показываем в заявке только действующие сервисы

Задача: убрать выведенные из эксплуатации сервисы из нового выбора

Учебный сценарий: поддержка принимает обращения по сервисам из Assets. В одном справочнике есть действующие и выведенные из эксплуатации объекты, а поле заявки предлагает всё подряд. Клиент выбирает старый сервис, и агенту приходится уточнять контекст. Настроим отдельное поле, в котором для нового выбора доступны только действующие сервисы. Исторические связи с прежними объектами при этом не будем удалять.

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

Применимость и условия запуска

Руководство относится к Assets for Cloud и полю Assets objects в Jira Service Management Cloud. Фиксированной версии облачной установки нет; названия пунктов могут отличаться при постепенном обновлении интерфейса. В актуальной справке Atlassian Assets указан для платных планов Jira, Jira Service Management и Service Collection, а также сайтов Teamwork Collection. Перед пилотом проверьте включённые возможности и лимит объектов именно своей подписки. Эти условия не означают, что все дополнительные инструменты Assets доступны на каждом плане.

Нужны права на подготовку тестовой схемы, лицензированный пользователь Jira с правом создания и настройки поля и администратор сервисного проекта, который добавит его на нужный экран и тип запроса. Роли приложения Assets, роли схемы и права Jira проверяются отдельно. Для Data Center используйте документацию своей версии: облачный путь настройки и модель доступа нельзя переносить туда автоматически.

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

В отдельной схеме пилота создайте тип Service с текстовым или Select-атрибутом Lifecycle. Для примера договоримся о точных значениях Active и Retired. Это пользовательский атрибут, а не встроенный статус Jira или обязательная терминология Atlassian. Не переименовывайте ради примера существующие производственные атрибуты. Запишите имена схемы, типа и атрибута, их назначение и ответственного за актуальность.

Подготовьте два объекта Service со значением Active, один Service со значением Retired и один объект другого типа, например Computer, тоже со значением Active. Используйте нейтральные названия «Пилот А», «Пилот Б», «Старый пилот» и «Тестовое устройство». Сохраните ключи объектов как контрольный набор. Не включайте дочерние типы в этот первый пилот: их поведение лучше согласовать отдельно.

Откройте расширенный поиск Assets в выбранной схеме и выполните приведённый AQL. Ожидаются только два действующих сервиса. Если результат другой, проверьте данные и имена до настройки поля. При доступном Display name учитывайте, что AQL обращается к имени сущности Name, а не к её отображаемому названию.

objectType = "Service" AND Lifecycle = "Active"

Шаг 2. Настройте отдельное поле для пилота

В администрировании Jira откройте Settings → Work items → Fields и создайте поле типа Assets objects с названием «Сервис — пилот». Через меню поля перейдите в Contexts and default values, затем Edit Assets object/s field configuration. Ограничьте контекст согласованным тестовым проектом и нужными типами задач. Снимок исходной конфигурации и ID поля сохраните в приватной рабочей записи.

Выберите тестовую Object schema и поместите AQL из предыдущего шага в Filter scope (AQL). Filter work scope (AQL), ранее называвшийся Filter issue scope, оставьте пустым: наш отбор зависит от данных справочника, а не от исполнителя или других полей задачи. Подстановки placeholders в Filter scope не поддерживаются. ORDER BY в этих настройках игнорируется; не делайте алфавитный порядок критерием приёмки.

В User interaction оставьте только согласованные атрибуты поиска и отображения, например название. Для одного сервиса в заявке не включайте хранение нескольких объектов. Автоматическую подстановку объекта на портале тоже оставьте выключенной: клиент должен осознанно выбрать сервис. Сохраните настройки и добавьте поле сначала только на тестовый рабочий экран.

Шаг 3. Проверьте рабочий экран и клиентский портал

Под агентом откройте тестовую задачу, найдите поле и выполните поиск по каждому контрольному названию. «Пилот А» и «Пилот Б» должны быть доступны; «Старый пилот» и «Тестовое устройство» — отсутствовать среди вариантов нового выбора. Сохраните выбранный сервис и повторно откройте задачу. Проверьте ключ объекта и обратную связь Connected Jira work items в Assets, а не только похожую подпись.

Теперь добавьте поле на тестовый тип запроса и сделайте его видимым на портале. Под отдельным клиентом повторите положительные и отрицательные проверки, создайте одну нейтральную заявку и откройте её снова. Проверьте поиск, карточку выбранного объекта и доступные атрибуты. Считайте пилот принятым только после сопоставления результатов агента и клиента. Это план проверки в вашей системе; при подготовке статьи действия на реальном Jira-сайте не выполнялись.

Добавление поля на тип запроса влияет на доступ: документация создания поля предупреждает об автоматическом предоставлении клиентам портала роли User для просмотра. Это нужно оценить до подключения реальной схемы. AQL-фильтр выбора не доказывает, что объект закрыт во всех остальных интерфейсах. Если справочник содержит закрытые сведения, остановите пилот и отдельно спроектируйте модель доступа.

Шаг 4. Проверьте изменение жизненного цикла без потери истории

На тестовой заявке сохраните ссылку на «Пилот А», затем в Assets измените его Lifecycle на Retired. В новой заявке он больше не должен предлагаться для выбора. Отдельно откройте старую заявку и запишите фактическое поведение: видна ли прежняя ссылка, открывается ли объект, что происходит при сохранении других полей и при попытке повторного выбора. Не обещайте пользователям автоматическую очистку старых значений.

Фильтр не является процедурой миграции уже заполненных заявок. Если для старых обращений нужен другой сервис, составьте отдельный реестр соответствий и согласуйте изменение ссылок с владельцем процесса. Не удаляйте объект из Assets, чтобы убрать его из выпадающего списка: так можно потерять полезный контекст расследования. Если конфигурация мешает обработке старых заявок, остановите распространение поля до отдельного решения.

Типовые ошибки: пустой выбор и разные результаты пользователей

При пустом выборе сначала проверьте схему и контрольный AQL в Assets, затем контекст поля, экран и тип запроса. Уточните, заполнен ли Lifecycle нужным значением, не используется ли другое имя атрибута и нет ли ошибки в кавычках. Не очищайте фильтр сразу на рабочем портале: это может открыть слишком широкий список. Диагностические изменения делайте на тестовом поле и возвращайте после проверки.

Если агент видит объект, а клиент нет, сравните пути доступа и набор отображаемых атрибутов под обеими учётными записями. Если клиент видит лишнее, уберите тестовое поле с портала до разбора. Проверяйте роли схемы и типа объекта вместе с правами Jira. Наличие правильного списка под администратором само по себе не подтверждает клиентский сценарий.

Не используйте поле как полный список всех объектов компании. Возможности хранения и отображения имеют ограничения и могут различаться между интерфейсами. Для этого сценария нужен один выбранный сервис; множество связанных компонентов лучше оставить в модели связей Assets. Расширение справочника обсуждайте после успешного малого пилота.

Откат и передача в сопровождение

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

Удаление поля с портала не считайте доказательством отмены всех выданных прав. Отдельно проверьте роли и группы схемы, оставшиеся пути доступа и сохранённые ссылки. Возвратите тестовые Lifecycle в исходное состояние, если это требуется продолжению пилота. Не запускайте массовое исправление старых заявок как часть такого возврата.

Перед рабочим включением назначьте владельца справочника и опишите правило смены Active на Retired, список контрольных объектов и порядок проверки после изменения AQL. Распространяйте настройку по одному согласованному типу запроса с повторной проверкой клиентского пути. Результат — понятный выбор действующего сервиса и сохранённая история, а не обещание универсальной защиты данных.