Компании в /task: как привязать проект к компании и выдать доступ участникам

Когда проектов становится больше десятка, а людей — больше двадцати, вопрос «кто должен видеть этот проект» перестаёт решаться вручную. В /task проект принадлежит не отдельному человеку, а компании: при привязке доступ к проекту автоматически получают участники этой компании, а руководители — управленческие права. Разбираем, зачем это нужно, как устроена привязка и отвязка в настройках компании и какие ошибки встречаются чаще всего.

Живое демо /task

Ниже — интерактивная демонстрация /task: можно переключать виды, открывать задачи и пробовать действия в интерфейсе.

Зачем привязывать проект к компании

Компания в /task — это организационная единица (юридическое лицо, подразделение или клиентская организация), у которой есть собственный список участников. Привязка проекта к компании превращает доступ из персонального в организационный: право видеть проект определяется членством в компании, а не списком приглашённых поимённо.

Что это даёт на практике:

• Онбординг без ручной работы. Новый сотрудник попадает в компанию — и сразу видит все её проекты. Не нужно обходить настройки каждого проекта.
• Один источник правды. Увольнение или смена роли закрывает доступ в одном месте, а не в десятке карточек.
• Изоляция клиентов. Проекты разных компаний не пересекаются: подрядчик видит только то, к чему привязан.
• Прозрачная ответственность. Понятно, чья это работа и кто отвечает за доступ.

Практическое правило: привязка к компании — для «своих» проектов и долгих отношений; персональные приглашения — для точечных исключений вроде внешнего аудитора.

Как это работает: участники и роли руководителей

Модель доступа в /task держится на трёх уровнях:

1. Компания. Хранит список участников. Каждый участник — пользователь с ролью внутри компании.
2. Проект. Привязан к компании и наследует её состав участников.
3. Роли руководителей. Отдельный уровень прав, который даёт управленческие возможности: менять настройки проекта, приглашать людей, работать с ролями и доступами внутри проекта.

Разделение важно: участник компании получает доступ к содержимому проекта — задачам, разделам, обсуждениям, — но не может менять состав участников и настройки. Руководитель компании (или руководитель проекта) получает расширенные права. Это классическая модель RBAC — ролевого управления доступом, где права выдаются роли, а не человеку напрямую.

Типовой набор ролей внутри проекта:

• Участник — видит проект, создаёт и редактирует задачи, оставляет комментарии.
• Руководитель проекта — управляет составом, настройками, полями и связями.
• Руководитель компании — видит и управляет всеми проектами компании, отвечает за привязку и отвязку.

Права не складываются «на глаз»: если человек одновременно участник и руководитель, действует более широкая роль. Это стоит помнить при разборе инцидентов доступа — сначала проверяйте роли, потом персональные исключения.

Привязка и отвязка в настройках компании

Управление привязкой живёт в настройках компании — это единая точка, где видно, какие проекты за ней закреплены. Порядок действий:

1. Откройте настройки компании, раздел с проектами.
2. Выберите проект из списка доступных и выполните привязку.
3. Проверьте состав: участники компании должны увидеть проект без дополнительных приглашений.
4. Назначьте руководителей проекта, если управление нужно делегировать.

При отвязке проект перестаёт наследовать участников компании. Важно понимать, что происходит с людьми:

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

Поэтому отвязка — не удаление. Это операция над правами, и выполнять её стоит осознанно: сначала проверьте, кто останется в проекте, затем отвязывайте.

Сценарий: подрядчик и несколько клиентов

Агентство ведёт проекты для трёх клиентов. Каждый клиент — отдельная компания в /task со своими участниками. Проекты привязаны к компаниям клиентов, а команда агентства добавляется как участники нужных компаний. Внутренние проекты агентства привязаны к собственной компании. Итог: клиент видит только свой проект, агентство — всё, что ему положено, а увольнение сотрудника закрывает ему доступ ко всем клиентским проектам сразу.

Сценарий: реорганизация

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

Плюсы и ограничения

Сильные стороны подхода:

• меньше ручных приглашений — меньше ошибок и «забытых» доступов;
• быстрый онбординг и такой же быстрый оффбординг;
• чёткая граница между «своими» и внешними участниками;
• предсказуемая модель прав, которую легко объяснить новичку.

Ограничения тоже есть, и о них лучше знать заранее:

• доступ по компании широкий: любой участник видит все привязанные проекты. Если проект чувствительный, его стоит держать отдельно или ограничивать персональными правами;
• смена компании у человека требует явных действий — автоматического переноса доступов нет;
• смешение моделей (компания плюс персональные приглашения) усложняет аудит. Заведите правило: исключения — временные и с датой пересмотра.

Чек-лист перед запуском

1. Составьте список компаний и определите, кто в них руководитель.
2. Разложите проекты по компаниям; чувствительные вынесите отдельно.
3. Назначьте руководителей проектов, а не только компании.
4. Проверьте доступ глазами рядового участника и глазами внешнего подрядчика.
5. Зафиксируйте процесс отвязки: кто инициирует, кто подтверждает, что делать с персональными приглашениями.
6. Раз в квартал пересматривайте исключения и роли.

Привязка проекта к компании в /task — небольшое действие в настройках, которое снимает целый класс рутины: приглашения, забытые доступы, споры «а почему он это видит». Настройте структуру компаний один раз — и дальше доступ будет следовать за людьми, а не за вашей памятью.