Применимость: Cloud. Названия пунктов и доступность функций зависят от версии, плана и типа проекта. Проверяйте изменения на тестовом окружении. Описанные рабочие процедуры — предлагаемый подход, а не гарантии поставщика.
Задача: заявка одного клиента видна его коллегам
Представим учебный сценарий: компания обслуживает нескольких клиентов через Jira Service Management. Сотрудник клиента создаёт заявку и ожидает, что её увидит только поддержка. Однако заявка оказывается доступна другим участникам его клиентской организации. Такое поведение может соответствовать настройкам совместной работы, но не ожиданиям автора. Задача администратора — установить фактическую аудиторию, согласовать модель доступа и проверить изменения обычными клиентскими аккаунтами. Здесь не описывается реальный инцидент или выполненный клиентский проект.
Руководство предназначено для JSM Cloud. У облачного сервиса нет фиксированной устанавливаемой версии; в интерфейсе могут встречаться названия project и space. Для Data Center нужны инструкции именно вашей версии. Организации клиентов JSM не следует путать с организацией в Atlassian Administration: в этом сценарии речь идёт о группировке клиентов службы поддержки. При добавлении клиентской организации к заявке её участники получают доступ к этой заявке; само членство не делает все личные обращения автоматически общими.
Подготовьте безопасный пилот и ожидаемую аудиторию
Для проверки возьмите отдельный тестовый сервисный проект и два обычных клиентских аккаунта А и Б одной тестовой организации. Третий аккаунт В оставьте вне неё. Не используйте реальные финансовые сведения, персональные данные или секреты. Создавайте заявки с нейтральным описанием и без вложений. В таблице пилота заранее запишите ожидаемый результат для каждого пользователя: кто создаёт заявку, кто должен её читать и кто не должен видеть даже подробности по прямой ссылке.
Для изменения проектных Customer permissions нужен администратор сервисного проекта. Глобальную настройку JSM согласуйте с администратором Jira и владельцами остальных проектов, поскольку её область действия шире пилота. Зафиксируйте исходные значения, состав тестовой организации и уже существующие правила Automation. Сохраните список ключей тестовых заявок. Отдельно проверьте, что аккаунты Б и В не являются агентами, администраторами или участниками рассматриваемой заявки: расширенные права исказят результат проверки.
Разделите три независимые настройки
Сначала откройте тестовую заявку со стороны агента и посмотрите поле Organizations и список Request participants. Затем проверьте настройки Customer sharing в разделе Customer permissions. Это разные пути получения доступа: удаление организации из заявки не означает удаления индивидуальных участников. Не делайте вывод о конфиденциальности по отсутствию письма. Уведомление сообщает о событии, а возможность открыть обращение проверяется отдельно.
В конфигурации JSM найдите параметр автоматического предоставления новой заявки организации автора: Should new requests automatically be shared with a customer's organization? Значение No меняет поведение по умолчанию, но не запрещает автору вручную выбрать организацию. В проектных настройках отдельно проверьте Sharing requests with organization и разрешения на предоставление доступа другим клиентам. Выбирайте их согласно согласованной модели, а не ради исчезновения одного элемента формы. Зафиксируйте, какие ограничения действуют именно на вашем сайте.
Измените настройки в согласованной области
Если обращения должны оставаться личными по умолчанию, после согласования измените глобальный параметр автоматического предоставления доступа организации на No. В разных вариантах навигации конфигурация может находиться под Jira Apps или Products, затем Jira Service Management и Configuration. Проверяйте текст самого параметра. После сохранения создайте новое обращение: старые заявки нельзя считать исправленными только потому, что глобальное значение изменилось.
Если политика проекта требует ограничить и ручное предоставление доступа, настройте соответствующие проектные переключатели организации и Customer sharing. Для пилота сначала запишите исходный режим и проверьте, не используется ли выбор клиентов при согласовании обращений. Не расширяйте глобальный доступ к порталу и не добавляйте пользователей в организации ради удобства теста. Автоматическое очищение Organizations после создания не используйте как доказательство отсутствия первоначального раскрытия: действие выполняется после события, а уведомления и другие процессы могли уже начаться.
Выполните матрицу проверок через портал и почту
В отдельной сессии аккаунта А создайте через портал новую заявку, оставив доступ никому из организации, если форма предлагает такой выбор. Посмотрите поле Organizations со стороны агента. Аккаунтом Б проверьте список обращений и прямую ссылку на новую заявку; повторите это аккаунтом В. Затем создайте второй тестовый запрос через подключённый почтовый канал. Укажите в письме только адрес поддержки, без копий и дополнительных получателей. Снова проверьте организацию, участников и возможность открыть заявку.
Если совместная работа разрешена политикой, проведите положительный тест: явно предоставьте доступ тестовой организации и убедитесь, что Б может открыть заявку, а В не может. Если такая возможность запрещена, вместо этого проверьте отсутствие доступного действия в клиентском интерфейсе и сохранение ожидаемой аудитории. Для каждого сценария фиксируйте ключ заявки, канал, значения полей и результат просмотра. Это предлагаемый план проверки; он не выполнялся в вашей Jira и не является утверждением о проверенной конфигурации.
Разберите ошибки, которые маскируют проблему
Если Б продолжает видеть обращение, проверьте, не осталась ли организация в конкретной заявке и не добавлен ли Б индивидуальным участником. Сравните права его аккаунта с обычным клиентом. Посмотрите историю изменений: организация могла быть назначена другим правилом или агентом после создания. Проверяйте каждый канал отдельно. Успех запроса через портал не подтверждает поведение почты, чата или интеграции, использующей другие параметры создания заявки.
Не отключайте уведомление Organization added в качестве способа ограничить доступ. Документация Atlassian отдельно отмечает, что без этого уведомления участники всё равно могут видеть обращение, предоставленное организации. Для автора, состоящего в нескольких организациях, предусмотрите отдельный тест: поведение выбора нельзя выводить из опыта аккаунта с одной организацией. Не считайте Organizations универсальной заменой уровней безопасности Jira и не переносите результаты клиентского портала на все внутренние роли проекта.
Откат и закрепление результата
При нарушении согласованной модели остановите расширение пилота. Восстановите сохранённые параметры только после согласования с владельцем процесса: возврат более широкого предоставления доступа сам по себе может быть нежелателен. Проверьте тестовые заявки отдельно, поскольку восстановление настроек не возвращает автоматически прежний состав участников. Если выявлено нежелательное раскрытие, удалите необоснованные пути доступа к конкретному обращению и действуйте по принятой процедуре инцидента. Уже доставленное письмо нельзя отозвать простым изменением Organizations.
Передайте владельцу сервиса таблицу проверок, согласованную модель и перечень исключений. Назначьте ответственного за добавление клиентов в организации и повторную проверку после изменения каналов, правил или состава групп. Для существующих заявок сначала оцените выборку и зависимости, затем составьте отдельный план исправления; массовое очищение поля без проверки может сломать нужную совместную работу. Критерий завершения — подтверждённая аудитория новых обращений в каждом используемом канале, а не только сохранённый переключатель администратора.
Официальная документация
Применить это к вашей системе
Обсудим контекст, ограничения и безопасный порядок изменений.
Обсудить задачу