Achilles — Harvester: ACL и личности

Вместе с контентом Harvester забирает из источника два сопутствующих набора данных — права доступа и личности людей — и держит их в актуальном состоянии наравне с самими сущностями. Harvester их производит; модель таблиц, хранение и резолюцию держит Knowledge Store. Права сохраняются в оригинальных терминах источника, без интерпретации; люди сводятся по email; синхронизация прав — часть общих режимов синхронизации, отдельного механизма под неё нет. Сам сбор и того, и другого идёт через коннектор — механику выборки держит sources.

1 Права доступа ACL источника переносится вместе с контентом.

ACL в оригинальных терминах

Harvester сохраняет права источника так, как их выдаёт сам источник: проект в Jira, пространство в Confluence, канал в Slack. Никакого маппинга на платформенные уровни доступа здесь нет — права забираются и сохраняются рядом с сущностью один к одному. Захват двусторонний: и тег группы на сущности (в каком проекте, пространстве, канале она лежит), и членство в группе — кто в неё входит; без обеих граней нельзя ответить, кому сущность доступна. Это сознательная граница: Harvester фиксирует, кому что было доступно в источнике, и не пытается решить, что это значит на платформе.

Интерпретация — не здесь

Перевод оригинального ACL в платформенные уровни доступа — задача других слоёв; Harvester не решает, кому что должно быть видно на платформе. Контракт прост: права переносятся вместе с контентом и сохраняются неискажёнными.

Применение на выдаче — pre-filter

Права применяются на запросе как pre-filter: кандидаты сужаются по доступу до ранжирования по близости — не «отранжировать и затем отбросить запретное» (так искажаются счётчики и пустеют страницы). Доступ резолвится джойном

пользователь → его личности → членства в группах
                  источника → группа-ACL сущности

; фрагмент наследует ACL сущности, своего не имеет. ACL и членство лежат в реляционной базе рядом с векторами — поэтому отбор по правам идёт тем же запросом, что и поиск по смыслу. Само применение — за слоем выдачи.

→ Query Engine

2 Личности (identity) Тот же коннектор отдаёт и людей; свод по email.

Один API — и контент, и люди

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

Свод по email · разбор несовпавших

Люди из разных источников сводятся в одну личность по email — явному и надёжному ключу. Кого по email сопоставить не удалось, Harvester не угадывает: такие записи уходят на ручной разбор в Admin Panel, где их привязывают к существующей личности или заводят как новую. При upsert личности Harvester заодно ставит мост к платформенному аккаунту того же email, если такой уже есть (identity.user_id) — та же авто-связь по точному email; правило держит Knowledge Store.

→ Admin Panel · Identity Mapping

Нечёткий свод — не здесь

Свод вида «разные email, но тот же человек» — нечёткое сопоставление личностей между источниками — Harvester не делает. Это задача deep entity resolution в Knowledge Store, за пределами нашей границы; здесь мы сводим только по точному совпадению email.

→ Knowledge Store

3 Синхронизация прав Часть общих режимов синхронизации, не отдельный механизм.

Права — на общих режимах синхронизации

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

Incremental · reconciliation

Incremental обновляет ACL точечно — по webhook или polling, как и сущности. Reconciliation делает полную сверку прав: выявляет то, что incremental упустил (пропущенные события, отзывы доступа), и приводит сохранённый ACL в соответствие с источником.

Отзыв вступает в силу с задержкой

Сохранённый ACL eventually consistent: между изменением в источнике и его синхронизацией есть окно. Для выдачи доступа это безопасно — пока новое право ещё не синхронизировано, человек видит меньше, чем ему уже разрешено, не больше. Для отзыва окно означает обратное: отозванное остаётся видимым до ближайшего incremental, partial re-sync или reconciliation — это принятый компромисс, а не недосмотр. Жёсткую гарантию «отозванное не утечёт в ответ» даёт не Harvester, а финальная проверка прав на самой выдаче — она находится за слоем запросов.

→ Query Engine