Применимость: Cloud. Названия пунктов и доступность функций зависят от версии, плана и типа проекта. Проверяйте изменения на тестовом окружении. Описанные рабочие процедуры — предлагаемый подход, а не гарантии поставщика.
Сценарий и границы задачи
В разработку подключается подрядчик. Ему нужны чтение задач и комментарии одного проекта, но нельзя менять версии, удалять задачи или управлять доступом. Сейчас права выдавались напрямую людям, поэтому администратор не может уверенно ответить, что увидит новый участник.
Пилот удобно проводить на проекте, где подрядчик ещё не участвует в реальной работе. Подготовьте вымышленные задачи с разными типами содержимого. Это позволит проверить права до добавления человека и избежать ситуации, когда корректность схемы выясняют уже после открытия рабочих документов.
Модель и договорённости
Постройте таблицу: роль, разрешённое действие, способ получения доступа, владелец согласования. Разделите исполнителя, наблюдателя и администратора. Название группы само по себе ничего не доказывает: проверьте, где она включена в роли, схемы и глобальные разрешения. Для каждого разрешения оставьте объяснимый бизнес-смысл.
Для роли наблюдателя отдельно решите судьбу комментариев и вложений. Чтение проекта часто воспринимают как доступ только к заголовкам, хотя задача может содержать существенно больше сведений. Попросите владельца данных подтвердить именно требуемый уровень доступа, а не просто согласовать расплывчатую формулировку «подключить к Jira».
Порядок внедрения
Найдите схему целевого проекта и список её потребителей. Если подрядчику нужен особый режим, сначала подготовьте отдельную копию схемы, затем свяжите её с пилотным проектом. Назначайте права роли, а людей добавляйте в эту роль. Уберите прямые назначения только после сравнения прежней и новой эффективной матрицы.
В журнале аудита доступа сохраните исходные назначения каждой изменяемой роли и перечень проектов, использующих схему. Для компании удобен отдельный перечень исключений: временное прямое право, причина, согласующий и дата снятия. Сначала проверьте роль наблюдателя, затем исполнителя, а административную роль оставьте отдельным этапом с более строгой проверкой.
Проверки на реальных сценариях
Создайте тестовые учётные записи сотрудника, подрядчика и постороннего пользователя. Для каждой проверьте чтение, создание, назначение, комментарий, вложение, переход и удаление задачи. Отдельно попробуйте прямую ссылку на чужую задачу и поиск. Отсутствие проекта в меню ещё не доказывает отсутствие доступа к его данным.
Отрицательный сценарий должен включать попытку назначения себе задачи, изменение её безопасности и управление участниками. Снимайте результат от имени тестового пользователя, не переключаясь на администратора между шагами. Если действие запрещено только интерфейсом, дополнительно проверьте соответствующий разрешённый способ работы через API.
Ошибки и диагностика
Типичная ошибка — проверить только подрядчика и случайно лишить робота интеграции права редактирования. Другая — убрать человека из одной роли, забыв о группе с более широким доступом. При неожиданном результате сравнивайте все пути выдачи прав; добавление ещё одной разрешающей группы обычно скрывает исходную причину.
Если пользователь сохраняет доступ после удаления из роли, проверьте членство в остальных группах и прямые назначения. Не объявляйте удаление участника завершённым только по изменению одного списка.
Возврат и восстановление
Сохраните соответствие проекта и прежней схемы, а также состав ролей перед изменением. При сбое верните ассоциацию схемы и восстановите только изменённые назначения. Не возвращайте массово всех пользователей в широкую группу. После отката повторите отрицательные проверки подрядчика: восстановление работоспособности не должно превращаться в расширение доступа.
Возврат начинайте с определения нарушенного действия: чтение, создание или переход. Если проблема только у интеграции, восстанавливайте её прежнюю роль, а не открывайте проект общей группе. После восстановления сравните матрицу подрядчика с первоначально одобренной и проверьте, что временное исключение действительно удалено после устранения причины сбоя.
Приёмка и дальнейший контроль
После внедрения считайте прямые назначения пользователей, роли без владельца и обращения о неожиданном доступе. Цель — объяснить право любого участника через согласованную роль. Ежеквартальный обзор состава роли полезнее формальной проверки названия схемы, потому что именно движение людей чаще всего меняет фактический периметр доступа.
В регламенте ухода подрядчика укажите проектные роли, группы и технические учётные записи. Удаление из проекта не обязательно закрывает другие пути доступа. Полезно хранить дату последнего подтверждения каждой внешней роли и ответственное лицо, которое может объяснить, зачем участник всё ещё нужен команде.
Механизм продукта и применимость
Схема разрешений определяет действия пользователей в проекте; Atlassian позволяет назначать разрешения проектным ролям. Изменение общей схемы следует рассматривать как изменение всех использующих её проектов.
Описанная работа с общей permission scheme относится к company-managed проектам Jira Cloud. В team-managed проектах доступ настраивается отдельной моделью проекта; копирование общей схемы туда не применяется. Начните с проверки типа проекта, а затем выбирайте соответствующий механизм ролей и ограничения доступа.
Официальная документация
Применить это к вашей системе
Обсудим контекст, ограничения и безопасный порядок изменений.
Обсудить задачу