Роли и права доступа

Доступ в Такте построен на ролевой модели (RBAC) с наследованием прав. Роли выстроены в цепочку: каждая следующая умеет всё, что предыдущая, плюс добавляет своё. Отдельно стоит гость (Anonymous) — он не входит в иерархию, а представляет человека до входа в систему.

Гость (Anonymous)          (вне иерархии)
   │ вход / регистрация / приглашение
   ▼
Наблюдатель ──▷ Участник ──▷ Скрам-мастер ──▷ Администратор ──▷ Владелец
(Viewer)        (Member)     (Scrum Master)    (Admin)           (Owner)
чтение          задачи       дисциплина        команда           жизненный
                и поток      потока             и доски           цикл

Источник истины прав — код (server/utils/rbac.ts и проверки requireMinRole в сервисах). Диаграммы ниже приведены в соответствие с ним: каждая показывает уникальный вклад роли — те действия, которые добавляются именно на её уровне; наследованные от предков права не дублируются, а обозначены стрелкой обобщения (──▷).

Гость (Anonymous)

Неавторизованный посетитель. Это параллельная роль: она не наследует прав Наблюдателя, а описывает сценарии «до сессии» — регистрацию, вход, подтверждение email и сброс пароля по ссылке из письма, принятие приглашения по magic-link. После любого из этих действий человек получает аутентифицированную роль (по умолчанию Member; конкретную роль в приглашении задаёт Admin).

Роль Anonymous: 5 сценариев доступа до получения сессии. Отправка письма вынесена в общий use case со связью «include» к внешнему актёру SMTP.

Наблюдатель (Viewer) — только чтение

Минимальная аутентифицированная роль и корень всей иерархии: её 18 сценариев наследуют все вышестоящие роли. Наблюдатель видит доски и участников, все виды доски (Kanban, календарь, timeline), всю аналитику потока (CFD, время цикла, throughput, прогноз Monte Carlo, рекомендацию по WIP, burndown) и получает уведомления — но ничего не меняет.

Роль Viewer: 18 базовых сценариев только на чтение, наследуемых всеми ролями выше.

Участник команды (Team Member) — работа с задачами

Основной исполнитель. Добавляет к чтению всё, что нужно ежедневно: создание и редактирование задач, перемещение по колонкам (с учётом WIP-лимитов), назначение исполнителя, смену класса обслуживания, story points, подзадачи, блокировки, чек-листы и комментарии с упоминаниями. Прикрепление файлов спроектировано, но пока не реализовано — на диаграмме оно помечено как запланированное.

Роль Team Member: 14 сценариев работы с задачами и потоком поверх 18 наследованных. Жёлтым — запланированное прикрепление файлов.

Скрам-мастер (Scrum Master) — дисциплина потока

Первичная персона продукта. Скрам-мастер управляет тем, ради чего Такт и строится, — дисциплиной потока: создаёт и ведёт спринты (планирование, capacity, старт, закрытие), настраивает структуру доски и WIP-лимиты (создание, переименование, переупорядочивание, удаление колонок), настраивает и пересчитывает SLE, отмечает пополнение очереди (replenishment) и может принудительно перенести задачу через WIP-лимит с обязательным указанием причины. С релиза 0.2 скрам-мастер также ведёт правила автоматизаций доски (создание, параметры, включение) и помечает колонки-очереди для расчёта эффективности потока.

Роль Scrum Master: 15 сценариев управления потоком поверх 32 наследованных. Управление WIP-лимитами, SLE и пополнением — зона ответственности именно этой роли.

Администратор (Admin) — команда и доски

Управляет составом: приглашает участников, меняет их роли, удаляет из рабочего пространства. Создаёт и переименовывает доски. Выполняет «жёсткое» удаление задачи (с потерей её истории событий). Удаление доски — операция более необратимая (каскад на колонки, задачи и события) — поднято на уровень Владельца.

Роль Admin: 6 сценариев управления командой и досками поверх 47 наследованных.

Владелец пространства (Workspace Owner) — жизненный цикл

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

Роль Workspace Owner: 6 сценариев жизненного цикла поверх 53 наследованных. Жёлтым — запланированная передача владения.

Как есть: пятиуровневая модель с наследованием работает и проверяется на уровне сервисов (requireMinRole) и на уровне БД (Row-Level Security). В планах: прикрепление файлов (Member) и передача владения (Owner) — помечены на диаграммах как запланированные.