# Видимость записей

> Четыре уровня видимости записи в организации, правило, которое сервер применяет на каждом чтении, и как видимость поменять.

Из этой страницы вы узнаете:

1. какие уровни видимости есть у записи в организации и кто видит каждый;
2. какую видимость получает новая запись;
3. как видимость поменять и почему обойти правило через агента нельзя.

## Уровни

| Видимость | В кабинете | Значение в API | Кто видит |
|---|---|---|---|
| Только автор | «только мне» | `author` | Только автор. Это черновик: его не видят ни руководитель, ни администратор, пока автор работает в организации |
| Отдел | «отделу» | `unit` | Люди узла записи и всех узлов ниже; руководители и администратор, в чьё поддерево входит этот узел |
| Проект | «проекту» | `project` | Действующие участники организации, работающие в проекте записи, в том числе подрядчики. Ключ, привязанный к другому проекту, такую запись не находит |
| Вся организация | «всей организации» | `organization` | Все действующие участники организации, кроме подрядчиков |

Исключения для ролей:

- **подрядчик** видит только свои записи и записи с видимостью «проект»;
- **аудитор** не видит ни одной записи;
- человек, которого увольняют или уже уволили, а также человек с истёкшим сроком доступа, не видит ничего;
- **получатель знаний** уволенного сотрудника видит все его записи, включая черновики, — см. [Увольнение](/organizations/offboarding/).

## Какую видимость получает новая запись

Видимость ставит сервер при `remember`, агент её не выбирает:

| Кто сохраняет | Видимость новой записи |
|---|---|
| Сотрудник, руководитель, администратор | «отделу» — узел, к которому прикреплён автор |
| Подрядчик | «проект» |

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

## Где проверяется правило

Правило превращается в условие SQL-запроса и применяется внутри запроса, а не фильтром после него. Это сделано на всех путях чтения:

- `search` и граф связей в результатах поиска;
- `validate_memory`;
- `forget` — нельзя удалить запись, которую вы не видите;
- кабинет: вкладка «Память» организации и «Знания сотрудников»;
- [архивариус](/memory/archivist/) — он связывает новую запись только с записями, которые видит её автор.

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

```text
  Агент Бориса ── search("как выкатывать staging") ──► MMW
                                                        │
                    SQL: записи организации, где
                    (автор = Борис)
                    ИЛИ видимость = «организация»
                    ИЛИ видимость = «проект»
                    ИЛИ (видимость = «отдел» И узел ∈ Бэкенд, Разработка, Северный ветер)
                                                        │
  ◄──────────────── только разрешённые записи ──────────┘
```

## Пример

В «Северном ветре» четыре записи:

| Запись | Автор | Видимость |
|---|---|---|
| «Staging выкатывается через systemd-юнит app-staging» | Анна | отделу (Бэкенд) |
| «Кандидат на замену очереди — NATS, сравниваю» | Борис | только автор |
| «API клиента X: лимит 100 запросов в минуту» | Вера | проект |
| «Релизы — по вторникам» | Дмитрий | вся организация |

Кто что найдёт:

| Человек | Staging | NATS | Лимит API | Релизы |
|---|---|---|---|---|
| Борис (сотрудник, Бэкенд) | да | да, свой | да, если работает в проекте | да |
| Анна (руководитель Бэкенда) | да, своя | нет | да, если работает в проекте | да |
| Дмитрий (администратор, корень) | да | нет | да, если работает в проекте | да, своя |
| Вера (подрядчик) | нет | нет | да, своя | нет |
| Глеб (аудитор) | нет | нет | нет | нет |

Черновик Бориса про NATS не видят ни Анна, ни Дмитрий. Если Бориса уволят и передадут знания Анне, она увидит и этот черновик.

## Как поменять видимость

**Знания уволенного сотрудника.** Получатель открывает вкладку «Знания сотрудников» → «Открыть записи» и для каждой записи выбирает в списке «Кому видно»: только мне, отделу, проекту или всей организации. Каждая такая смена попадает в [журнал](/organizations/audit-log/).

**Свои записи.** Сервер разрешает автору менять видимость своих записей через API кабинета; отдельного переключателя для своих записей в интерфейсе кабинета пока нет. Запрос отправляется от имени вошедшего в кабинет пользователя, организация указывается заголовком `X-MMW-Space`:

```http title="Сделать свою запись черновиком"
PATCH /api/v1/org/memories/4d428a41-e7b0-4f81-a886-f40c6f6c766c
X-MMW-Space: <ID организации>
Content-Type: application/json

{ "visibility": "author" }
```

Ответ:

```json
{ "id": "4d428a41-e7b0-4f81-a886-f40c6f6c766c", "visibility": "author", "org_node_id": "…" }
```

Допустимые значения `visibility`: `author`, `unit`, `project`, `organization`. С полем `"to_my_unit": true` запись переносится в ваш текущий узел — так «отделу» начинает означать ваш новый отдел. Менять можно только свои записи и записи, переданные вам при увольнении; на чужую запись сервер ответит `memory_not_found`.

API-ключ `mmw_…` для этого запроса не подходит: это действие кабинета, а не инструмент MCP. Через инструменты MCP видимость не задаётся.

Видимость «холдинг» и обмен записями между юрлицами холдинга сейчас выключены: такие записи остаются только у автора.

## Что дальше