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

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

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

Уровни

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

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

подрядчик видит только свои записи и записи с видимостью «проект»;
аудитор не видит ни одной записи;
человек, которого увольняют или уже уволили, а также человек с истёкшим сроком доступа, не видит ничего;
получатель знаний уволенного сотрудника видит все его записи, включая черновики, — см. Увольнение.

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

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

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

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

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

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

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

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

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

Пример

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

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

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

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

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

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

Знания уволенного сотрудника. Получатель открывает вкладку «Знания сотрудников» → «Открыть записи» и для каждой записи выбирает в списке «Кому видно»: только мне, отделу, проекту или всей организации. Каждая такая смена попадает в журнал.

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

PATCH /api/v1/org/memories/4d428a41-e7b0-4f81-a886-f40c6f6c766c
X-MMW-Space: <ID организации>
Content-Type: application/json

{ "visibility": "author" }

Ответ:

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

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

Что дальше

Увольнение и передача знаний Кто получает черновики ушедшего и как открыть их команде.

Структура и роли Что может каждая роль.

Проекты и рабочие области Как ключ привязывается к проекту.

Журнал организации Что записывается при смене видимости.