# Права доступа к задачам

> **⚠️ «Роль» — 3 разных смысла.** В 1Форме «роль» означает одно из трёх: (1) **роль в задаче** (participant role — заказчик/исполнитель/подписчик, объектная роль); (2) **роль бизнес-процесса** (workflow role — `BpRoles`: создаётся в модуле запросом `POST api/modules/{moduleId}/roles`, привязывается к переходам и подписям); (3) **платформенная роль** (RBAC role — `Roles`, ролевая модель users-and-groups). При поиске/настройке уточняйте какая. См. [`users-and-groups/admin.md`](https://help.1forma.ru/domains/users-and-groups/admin.md) для RBAC и [`categories/admin.md`](https://help.1forma.ru/domains/categories/admin.md), раздел «6. Статусы и переходы» → «Роли бизнес-процесса на графе маршрута», «Создание роли бизнес-процесса в модуле» — для workflow-ролей.

Документ описывает бизнес-правила прав доступа к задачам в 1Форме: общий принцип «доступ хотя бы по одному из уровней», доступ на категорию, доступ на задачу по роли, доступ акцептанта и заместителя, смарт-доступ, доступ через SQL-представление, гибкая настройка прав через ДП (ABAC / field-driven ACL — прямой выбор, связанная категория, цепочки, выбор нескольких задач), конфиденциальные и зашифрованные задачи, матрица доступа к ДП (field-level security) и устаревшие механизмы. Целевая аудитория — администраторы категорий, инженеры поддержки и пользователи, разбирающиеся в правилах видимости задач.

## 1. Общий принцип и доступ на категорию

Пользователь получает доступ на просмотр задачи, если соответствует **хотя бы одному** требованию:

1. Доступ на категорию
2. Доступ на задачу (по роли)
3. Смарт-доступ
4. Доступ через SQL-представление
5. Акцептант активной подписи
6. Заместитель сотрудника с одним из указанных прав

> **Исключение**: конфиденциальные задачи — доступ имеют **только подписчики**, прочие уровни не учитываются.

```mermaid
flowchart TD
    A["Может ли пользователь видеть задачу?"] --> K{"Задача конфиденциальная?"}
    K -- "да" --> L["Доступ только у подписчиков; прочие уровни не учитываются"]
    K -- "нет" --> B{"Доступ хотя бы по одному уровню?"}
    B --> C["Право группы на категорию"]
    B --> D["Роль в задаче: заказчик, исполнитель, подписчик, руководитель"]
    B --> E["Смарт-доступ"]
    B --> F["Доступ через SQL-представление"]
    B --> G["Акцептант активной подписи"]
    B --> H["Заместитель сотрудника с правом доступа"]
    C --> Y["Задача видна"]
    D --> Y
    E --> Y
    F --> Y
    G --> Y
    H --> Y
    B -- "ни одного" --> N["Задача не видна"]
```

Права выдаются **группе пользователей** на уровне категории.

Если пользователь входит в несколько групп — права **суммируются** (учитываются все активные права).

Модель доступа действует не только при открытии карточки задачи, но и при **отборе задач в производных представлениях** — в календаре и во «Входящих» (LeadIn): туда попадают только задачи, доступные пользователю хотя бы по одному из уровней выше. Конфиденциальные задачи следуют тому же исключению (доступ только у подписчиков; при этом в календаре сохраняются свои события и участие во встрече).

### Виды прав группы на категорию

Группе можно выдать на категорию следующие права:

| Право | Описание |
|-------|----------|
| **Администратор задач/категории** | Изменение любых параметров: заказчик, исполнитель, сроки, текст, подписи, статус вопреки маршруту. Право разрывать связи между задачами (если задачи в разных категориях — право нужно хотя бы в одной). Единственное право, открывающее кнопку **«Удалить»** в контекстном меню грида и карточки задачи |
| **Просмотр всех задач** | Видеть все задачи в категории |
| **Создавать задачи** | Создание объектов (пользователь выступает как Заказчик) |
| **Исполнять** | Принятие задач к исполнению |
| **Редактировать исполнителей** | Редактирование параметра «Исполнители» |
| **Менять заказчика** | Смена заказчика задачи |
| **Переносить срок** | Редактирование «Срок исполнения» |
| **Добавлять и менять акцептантов** | Добавление акцептантов к запрошенной подписи, делегирование. Работает независимо от настройки подписи «Можно делегировать» |
| **Пакетная обработка** | Пакетные операции над задачами |
| **Просмотр зашифрованных задач** | Доступ к тексту и ДП в зашифрованных задачах (иначе — «текст задачи скрыт») |
| **Видеть скрытую оценку исполнителей** | Доступ к оценке при режиме «Закрытая оценка» |
| **Запретить экспортировать в Excel** | Запрет выгрузки данных по категории |

Права на категорию назначаются в двух местах (двусторонняя навигация):

- **Настройки категории** → вкладка «Доступ» — назначение групп с правами
- **Управление группами** → вкладка «Права на категорию» — обратная навигация

## 2. Доступ на задачу (по роли)

Для отдельной задачи права определяются **ролью пользователя** в ней:

- **Заказчик**
- **Исполнитель**
- **Подписчик**
- **Руководитель исполнителя**
- **Руководитель заказчика**

Назначение ролей происходит в пользовательском интерфейсе задачи.

Ролевой доступ к задаче действует одинаково в представлениях категории «Таблица» и «Иерархия»: если у пользователя есть доступ хотя бы по одной роли, задача видна и в табличном, и в иерархическом представлении (даже без права «Просмотр всех задач»).

**Дерево подзадач.** В окне подзадач (панель инструментов карточки задачи) подзадачи без права просмотра не скрываются, а показываются как структурные узлы с пометкой «Нет доступа» — это сохраняет иерархию для доступных дочерних задач. Подробнее — в разделе [«Подзадачи и иерархия» → «Права доступа и связи»](https://help.1forma.ru/domains/tasks/business.md#права-доступа-и-связи).

### Запрещённая задача: что видно без доступа

Если у пользователя нет доступа к задаче, он не получает ни одного её признака: ни названия, ни статуса, ни владельца, ни состава участников. Единственный ответ — нейтральное сообщение об отсутствии доступа.

Правило действует не только при открытии карточки, но и на косвенных путях, где задача упоминается:

- поиск задачи по номеру — отказ без имён;
- страница ошибки `403` при переходе по прямой ссылке — без владельца со ссылкой на профиль и без блока запроса доступа у конкретных сотрудников: страница получает только адрес и текст отказа, поэтому данных задачи в ней нет;
- ответы промежуточных слоёв — краткая модель задачи (владелец, исполнители, статус, название), которую сервер успел приложить к ответу, отбрасывается: интерфейс переводится на пустое значение и показывает нейтральный отказ.

## 3. Доступ акцептанта и заместителя

**Акцептант подписи** получает право на просмотр задачи в период, когда подпись **запрошена, но ещё не обработана** (статус «На подписи»).

Два сценария после обработки подписи:
- Настройка «Добавлять в подписчики акцептанта» **включена** → акцептант становится подписчиком, доступ сохраняется
- Настройка **выключена** → акцептант теряет доступ после подписания/отклонения

**Акцептант конфиденциальной задачи.** Право на просмотр задачи и доступ к её содержимому — разные вещи. Акцептант видит конфиденциальную задачу в списках и ленте, но карточку не открывает и содержимого не видит: текст задачи и значения дополнительных параметров приходят с заглушкой. Содержимое становится доступным, только если акцептанта добавили в подписчики — настройкой «Добавлять в подписчики акцептанта» или вручную. Если акцептант содержимого не получил, порядок его работы с задачей не меняется.

**Заместитель** получает доступ ко **всем задачам принципала**, за исключением:

- **Конфиденциальных задач** — заместитель НЕ получает доступ к конфиденциальным задачам принципала
- Категорий с ограничением в дополнительных настройках замещения (по умолчанию режим «Кроме категорий» — недоступны чаты и приватные задачи в категориях с конфиденциальностью/шифрованием)
- Зашифрованных задач, к которым у заместителя нет собственного доступа
- Чатов принципала, к которым у заместителя нет доступа

## 4. Смарт-доступ и SQL-представление

**Смарт-доступ** предоставляет права на **отдельные задачи** в зависимости от условий, определённых смарт-выражением.

Смарт-выражение возвращает список пользователей, которым предоставляется доступ к задаче.

**Доступ через SQL-представление** позволяет администратору настроить на уровне категории доступ через SQL-представление, которое возвращает пары «пользователь — задача»: каждая такая пара открывает пользователю доступ на чтение указанной задачи. Технические детали настройки — в [admin.md](https://help.1forma.ru/domains/permissions/admin.md).

> **Важно**: права доступа на категорию имеют **больший вес**. Если у пользователя нет доступа к категории, а через SQL-представление доступ предоставлен — доступ **не действует**.

## 5. Гибкая настройка прав через ДП

Механизм предоставления доступа к задачам через ДП «Выбор пользователя» — с поддержкой цепочек через Lookup-поля.

### Режимы 1-2: прямой выбор пользователя и связанная категория

**Режим 1. Прямой выбор пользователя**

В категории есть ДП «Выбор пользователя». Пользователь, добавленный в этот ДП, получает доступ к задаче.

**Пример**: ДП «РП (Руководитель проекта)» и «СДО» в категориях договоров — пользователи из этих ДП получают доступ к задачам.

**Режим 2. Через связанную категорию**

В категории **A** есть ДП «Lookup поле» на категорию **B**. В категории **B** есть ДП «Выбор пользователя». Пользователи из ДП категории B получают доступ к задаче категории A.

**Пример**: категория «Backlog проектных задач» → Lookup на «Модули ТМ» → ДП «Акцептант» типа «Выбор пользователей» → доступ к задачам Backlog.

### Режимы 3-4, цепочки и важное ограничение

**Режим 3. Через цепочку из двух связей**

Цепочка из трёх категорий:

1. Категория **A** — ДП «Lookup поле» на категорию **B**
2. Категория **B** — ДП «Сквозной», обращается к категории **C** по Lookup-полю из той же категории B
3. Категория **C** — ДП «Выбор пользователей» → доступ к задаче категории A

**Пример**: «Проекты» → Lookup «Договор» → «Договоры» → Сквозной «КМ» по Lookup «Клиент» → «Клиенты» → ДП «Клиентский менеджер» → доступ к проектам.

**Режим 4. Через выбор нескольких задач**

В категории **A** есть ДП «Выбор нескольких задач из категории» на категорию **B**. В **B** есть ДП «Выбор пользователя» → доступ к задаче категории A.

**Пример**: категории разработки (Backlog, Backlog несоответствия, Backlog ошибки) → ДП «Компании» (Выбор нескольких задач) → «Клиенты» → ДП «КМ» → доступ к задачам.

**Важное ограничение**

Настройка гибких прав производится **для конкретных параметров и категорий**. Если ДП распределяет доступ в одной категории, это не распространяется на другие категории, где этот ДП также присутствует.

## 6. Конфиденциальные и зашифрованные задачи

При включённом режиме «Конфиденциально» на задаче — доступ имеют **только подписчики**. Все остальные уровни доступа (категория, роль, смарт-доступ, SQL-представление) **не работают**.

**Режим конфиденциальности категории.** Кроме флага на отдельной задаче, есть настройка категории с тремя значениями: конфиденциальность выключена, разрешено ставить флаг на задачах категории, все задачи категории конфиденциальны. В третьем режиме доступ к задачам имеют только их подписчики — независимо от прав, выданных на категорию; такая категория целиком исключается из кеша прав, поэтому её задачи не попадают в ленту и списки тем, кто не подписан. Поведение одинаково на обеих поддерживаемых СУБД.

Во втором режиме («разрешено ставить флаг») пометка «Конфиденциально» на задаче отсекает всех, кроме подписчиков. Если конфиденциальность у категории выключена, пометка, оставшаяся на задаче, доступ по праву на категорию не ограничивает: такая задача видна всем, у кого есть право на категорию. Поведение одинаково на обеих СУБД.

Матрица взаимодействия конфиденциальности и шифрования с замещением / перевоплощением:

| Механизм | Замещение | Перевоплощение (сисадмин) |
|---|---|---|
| **Конфиденциальность** | Доступ запрещён | Доступ **есть** (так задумано) |
| **Шифрование** | Доступ запрещён | Доступ запрещён (текст/комментарии/файлы скрыты) |
| **Конфиденциальность + Шифрование** | Доступ запрещён | Доступ запрещён |

> Для максимальной защиты (включая защиты от перевоплощения) необходимо включать **шифрование**. Конфиденциальность ограничивает подписку и замещение, но не блокирует перевоплощение.

**Генерация документа по шаблону.** Если пользователь формирует файл по шаблону Word и в данные попадает конфиденциальная задача без доступа к содержимому, генерация не прерывается: вместо значений дополнительных параметров в файл записывается заглушка. При наличии доступа документ заполняется полностью, а порядок задач в цикле шаблона по значению параметра сохраняется. Подробнее — в [шаблонизаторе печатных форм](https://help.1forma.ru/domains/reports/academy-patterns.md).

При перевоплощении в пользователя, у которого нет права «Просмотр зашифрованных задач», скрывается:

- **Зашифрованные ДП** в карточке задачи — отображаются пустыми;
- **Текст задачи** в табличном представлении — не показывается;
- **Файлы** зашифрованной задачи — недоступны для скачивания и просмотра;
- **Комментарии** — текст зашифрованных комментариев скрыт.

### Что видно пользователю без доступа к содержимому

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

**Скрывается** всё, что раскрывает содержание задачи: текст задачи, значения дополнительных параметров — включая вложенные файлы, участников и связанные задачи, — состав и количество вложений, номера и тексты подзадач и связанных задач.

**Остаётся видимым** то, что содержания не раскрывает: номер задачи, категория, состояние и сроки. Сама задача из списка не пропадает.

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

Правило действует во всех списочных выходах — представления категории, лента задач, выгрузка в Excel и CSV — и в письмах: получателю без доступа к содержимому письмо по конфиденциальной задаче приходит без текста задачи, значений ДП, вложений и без заданной администратором приставки темы, но с событием, номером задачи и ссылкой на неё. Доступ считается по каждому получателю отдельно. Подробнее — в разделе [«Почта» → «Конфиденциальные задачи в письмах»](https://help.1forma.ru/domains/mail/business.md#конфиденциальные-задачи-в-письмах).

**Группировка и список значений колонки.** В табличном представлении заголовок группы по дополнительному параметру подчиняется тем же правилам: группа, где есть хотя бы одна задача с доступным содержимым, выводит значение, а группа, все задачи которой закрыты, — метку «Скрыто N». Счётчик задач на группе и её место в списке остаются видимыми — скрывается только значение. В список значений фильтра «Выбор значений» закрытое значение не попадает, если в выборке нет ни одной доступной задачи с таким значением. В таблице дополнительного параметра типов «Таблица» и «Мультивыбор таблицы» правило применяется ко всей таблице сразу: таблица принадлежит одной задаче, поэтому при закрытом содержимом маскируются все группы. Подробнее — в разделе [«Гриды» → «Группировка»](https://help.1forma.ru/domains/grids/business.md#группировка).

**Итоги колонок.** В строке итогов действует то же правило. Если все задачи, попавшие в выборку итога, конфиденциальны и доступа к их содержимому у пользователя нет, вместо значения выводится заглушка «Скрыто», а в таблице ресурсов такая итоговая ячейка остаётся пустой. Если в выборке есть хотя бы одна доступная задача, итог считается как обычно; в этом случае маскируются только минимум и максимум и только тогда, когда их значение совпадает со значением по закрытой части выборки. Суммы, средние и счётчики выводятся обычными числами.


**В мобильном приложении** правило действует так же: вложения конфиденциальной задачи без доступа к её содержимому не приходят в мобильную ленту и дерево лент — имена файлов, размер и ссылки на скачивание не отдаются. Строки недоступных подзадач и связанных задач в мобильном дереве не показываются вовсе, вместе с номером; в десктопном дереве такая строка, наоборот, остаётся структурным узлом с пометкой «Нет доступа» (см. [«Подзадачи и иерархия» → «Права доступа и связи»](https://help.1forma.ru/domains/tasks/business.md#права-доступа-и-связи)). Текст задачи, попадающий в блок «Подписи» мобильного дерева лент, тоже берётся с проверкой доступа: без доступа вместо текста — заглушка. При создании задачи из конфиденциального родителя без доступа к его содержимому значения родителя в форму новой задачи не переносятся — в том числе вложения и состав участников; значения по умолчанию категории при этом сохраняются.

Значения дополнительных параметров конфиденциальной задачи закрыты и в мобильном списке, и в ленте, и в форме задачи: вместо строкового значения приходит та же заглушка, а типизированные значения (числовые, денежные, датовые, логические, справочные, выбор пользователя, файловые) пусты. Доступ считается для каждой задачи отдельно, поэтому на одной странице у доступной задачи значение видно целиком, а у конфиденциальной без доступа — закрыто. Под перевоплощением доступ проверяется и по реальному, и по подменённому пользователю: если доступа нет ни у кого из них, значение закрывается.
**Файл из ДП «Файл».** Обращение к файлу, лежащему в дополнительном параметре типа «Файл», проверяется не только по правам на параметр, но и по доступу к содержимому задачи-носителя: конфиденциальность и шифрование контекстной задачи проверяются до прав на параметр — и при чтении файла, и при его замене. Обладателю права на категорию, роли, гибкого или смарт-доступа без подписки файл не отдаётся, в том числе по сохранённой ссылке на него: сама задача при этом остаётся у него в списке. Проверяется именно та задача, из которой файл открывают, поэтому файл, привязанный ещё и к другой конфиденциальной задаче, из доступной задачи открывается как обычно. У задачи без признака конфиденциальности и у подписчика доступ к файлу не меняется.

**В списках и блоках подписей** правило действует так же. Акцептант подписи, не подписчик конфиденциальной задачи, в списке активных подписей видит саму подпись — задачу, срок, действия, — но вместо текста задачи получает заглушку, а значения дополнительных параметров приходят закрытыми: на месте строкового значения та же заглушка, типизированные значения пусты. Строка подписи не пропадает, недоступно только содержимое. То же — в блоке подписей на портале: подпись остаётся, текст задачи закрыт. При перевоплощении доступ к содержимому проверяется и по подменённому, и по действительному пользователю. У подписчика с доступом содержимое видно полностью, у задач без признака конфиденциальности состав ответа не меняется.
## 7. Матрица доступа к ДП и устаревшие механизмы

Помимо доступа к самой задаче, существует **матрица доступа к ДП** — управление видимостью и редактируемостью отдельных дополнительных параметров:

- По **роли** пользователя (заказчик / исполнитель / ответственный исполнитель / подписчик / акцептант / группа)
- По **статусу** задачи
- Гранулярность: чтение / редактирование / скрыт

Настраивается на уровне категории. Подробнее — в домене [Дополнительные параметры](https://help.1forma.ru/domains/ext-params/business.md).

**Устаревшие механизмы.** Некоторые механизмы доступа больше не используются:

- **Доступ по тегам** — устарел, не применяется.

## 8. Объектная авторизация в REST API

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

Порядок разбора запроса к объекту:

1. **Объект существует?** Если задачи, события, ящика или опроса с таким идентификатором нет — ответ 404.
2. **Есть ли права?** Если объект есть, но у пользователя нет прав на чтение или изменение — ответ 403.
3. **Чьи права проверяются.** Проверка идёт по пользователю сессии. При перевоплощении это целевой пользователь: в токене он записан в `SessionUserId`, а инициатор — в `OldUserId` (см. [Перевоплощение](https://help.1forma.ru/domains/permissions/impersonation.md)).

Объектная проверка действует, в частности, в следующих областях:

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

Коды ответов и правило «сначала существование, потом права» описаны в регламенте Проектирование API.