Организации, членство и права

Зачем нужно

Документ описывает продуктовую модель организаций в identity: справочник, рабочие организации, членство, роли, права, заявки, ученики организации, дубли, склейку, админ-модуль и аудит.

Канонический DDL находится только в ../database-schema.md. Канонические сущности и связи описаны в ../data-model.md. В этом файле нет CREATE TABLE, потому что feature-спека фиксирует поведение, сценарии и правила.

Базовое решение

На платформе нет глобальной роли «преподаватель». Пользователь — это аккаунт платформы, а доступ определяется контекстом:

1. членство в организации;
2. роль внутри организации;
3. команда внутри организации;
4. продуктовый модуль;
5. конкретный ресурс;
6. permission grant, если нужна точечная выдача или запрет.

Формула доступа:

user -> organization_membership -> role/grants/team -> permission -> resource

Организации остаются в identity и не становятся отдельным доменом. Product domains используют organization context, но не владеют организацией, членством, командой или учеником организации.

Learning Workspace остаётся единым преподавательским режимом. Внутри него пользователь выбирает организацию, а затем видит доступные подслои выбранной организации:

Подслой	Что означает	Источник доступа
Преподавательский	свои рабочие группы, ученики, назначения, прогресс, олимпиады и тренажёры	LMS workspace + assignments + product permissions
Административный	управление участниками, официальными учениками, командами и grants организации	active membership + organization role/grant
Площадочный	работа с очной площадкой олимпиады	competitions venue permissions в scope выбранной организации

Организация и площадка не становятся отдельными верхнеуровневыми пользовательскими контекстами рядом с преподавательским.

Teacher/helper/venue permissions живут внутри scope выбранной организации или конкретного product resource. Они могут открыть административный или площадочный подслой в Learning Workspace, но не создают отдельный top-level context “организация” или “площадка” рядом с преподавательским режимом.

Два слоя организаций

Слой	Сущность	Назначение	Даёт права
Справочная организация	organization_reference	Нормализованный поиск, подсказки, снижение дублей	Нет
Организация платформы	organization	Рабочий контур с владельцем, участниками, командами, правами, учениками и ресурсами	Да, через membership/roles/grants

organization_reference может существовать без рабочей организации. organization может быть создана вручную и не иметь reference_id.

Типы организаций

Тип	Значение
systematika	Внутренняя организация «Систематика»
school	Общеобразовательная школа
private_school	Частная школа
club	Кружок
education_center	Образовательный центр
commercial_center	Коммерческая образовательная организация
franchise	Франчайзи
foreign_organization	Зарубежная организация
other	Другое

Тип классифицирует запись, но не выдаёт права автоматически.

География и поиск

Для первого этапа используются:

• справочник стран;
• справочник регионов России;
• текстовое поле города или населённого пункта;
• справочник организаций;
• уже созданные организации платформы;
• fuzzy-поиск похожих названий.

Справочник городов не входит в MVP. Если country/region понадобятся шире организаций, перенос в platform reference-data оформляется отдельным ADR.

Статусы организации

Статус	Значение
draft	Создана, но ещё не подтверждена как рабочий контур
active	Активная организация с владельцем
unclaimed	Организация есть, но нет подтверждённого владельца
disputed	Есть спор за права или принадлежность
archived	Организация больше не используется
merged	Организация склеена с другой организацией

Правила:

• у active организации должен быть owner_membership_id;
• merged организация не удаляется физически и должна иметь merged_into_organization_id;
• disputed и merged меняет только системный администратор;
• hard delete по умолчанию запрещён.

Владелец организации

Владелец — active membership с owner-ролью. Простой ввод названия организации не делает пользователя владельцем.

Владелец может:

• управлять участниками организации;
• приглашать пользователей;
• подтверждать и отклонять заявки на вступление;
• назначать и снимать администраторов;
• управлять командами;
• назначать organization-local roles и grants;
• передавать владение другому участнику;
• видеть список учеников организации;
• выполнять product actions, если они разрешены доменом-владельцем.

Владелец не может:

• склеивать организации;
• менять системные статусы спорных организаций;
• обходить ручную модерацию «Систематики»;
• физически удалять организацию;
• удалять audit.

Членство

organization_membership связывает пользователя и организацию.

Статус	Значение
requested	Пользователь сам подал заявку
invited	Пользователь приглашён
active	Членство активно
rejected	Заявка отклонена
suspended	Членство временно приостановлено
left	Пользователь вышел из организации

Источник	Значение
self_request	Пользователь сам запросил вступление
invitation	Пользователь принял приглашение
admin_created	Членство создано администратором
ownership_claim	Членство возникло через заявку на владение
system_migration	Членство создано миграцией
system_action	Членство создано системным действием

Пользователь может состоять в нескольких организациях с разными ролями. В одной организации у пользователя не может быть двух active/pending-like membership.

Самозаявленный преподаватель может указать организацию в educator_profile и использовать её как заявленную связь в Learning Workspace. Это не создаёт active membership и не даёт доступ к чужим группам, официальной статистике организации, спискам organization_student или официальному контуру без подтверждения.

Приглашения

Приглашение создаёт владелец, администратор организации или системный администратор с нужным permission.

Приглашение содержит:

• организацию;
• отправителя membership;
• email или другой канал доставки;
• предложенную роль;
• token hash;
• срок действия;
• статус.

Статус	Значение
created	Приглашение создано
sent	Приглашение отправлено
accepted	Приглашение принято
expired	Срок действия истёк
revoked	Приглашение отозвано
rejected	Пользователь отказался

После принятия invitation пользователь получает active membership и роль из invitation.

Заявка на вступление

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

Если у организации есть владелец или администраторы, заявку подтверждают они. Если у организации нет владельца, пользователь может подать заявку на владение; её рассматривает только администратор «Систематики».

Заявка на владение

Заявка на владение нужна, когда пользователь хочет получить owner-права в существующей организации.

Типовые случаи:

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

Заявка содержит:

• заполненный профиль;
• ФИО;
• контактную почту и телефон, если используется;
• страну, регион, населённый пункт;
• название организации;
• должность или описание связи с организацией;
• evidence links;
• комментарий для модератора.

Статус	Значение
submitted	Заявка подана
needs_more_info	Нужны дополнительные данные
approved	Владение выдано
rejected	Заявка отклонена
cancelled	Пользователь отменил заявку
disputed	Случай признан спорным

Передача владения

1. Текущий владелец выбирает нового владельца.
2. Новый владелец должен быть active-членом организации или получить приглашение.
3. Создаётся organization_ownership_transfer.
4. Получатель подтверждает переход по ссылке, email или в кабинете.
5. После подтверждения owner_membership_id переходит к новому membership.
6. Старый владелец получает роль, указанную в transfer policy.
7. Действие пишется в audit.

Статус	Значение
created	Передача создана
sent	Получателю отправлено подтверждение
accepted	Получатель согласился
expired	Срок подтверждения истёк
cancelled	Передача отменена
completed	Передача завершена

Роли и permissions

Базовые роли организации:

Роль	Значение
owner	Владелец организации
admin	Администратор организации
member	Обычный участник
viewer	Только просмотр, если включён такой режим

Product roles не заменяют membership. Например, олимпиадный организатор или редактор банка задач получает product permission из домена-владельца, но organization context остаётся identity-owned.

Локальные permission names запрещены:

Не использовать	Использовать
organization.members.view	identity.organization-members.read.organization
students.view	identity.organization-students.read.organization
olympiad.results.edit	competitions.results.manage.organization
problem_bank.collections.edit	task-bank.collections.manage.organization

Все permissions в organization roles, team roles и grants должны существовать в общем catalog.

Команды

Команда — группа внутри организации. Она не существует без организации и не является отдельным владельцем данных.

Примеры:

• методисты;
• преподаватели 5–6 классов;
• олимпиадные организаторы;
• администрация;
• редакторы подборок задач.

На MVP команды можно заложить в модели и DDL, но включать в UI постепенно.

Permission grants

organization_permission_grant нужен, когда роли недостаточно.

Grant может быть выдан на:

• membership;
• organization team;
• organization role.

Grant может быть ограничен ресурсом:

permission + organization_id + optional resource_type/resource_id

permission всегда является ключом из общего catalog. Product resource остаётся во владении product domain.

Ученики организации

organization_student — официальная или подтверждённая запись ребёнка внутри организации. Ученик организации не обязан быть пользователем платформы.

Нужно разделять:

Сущность	Владелец	Назначение
student_profile	identity	семейный/учебный субъект ребёнка
organization_student	identity	официальный/подтверждённый ученик в списке организации
learning_group_participant	lms	рабочий ученик преподавателя внутри Learning Workspace
competition_participant	competitions	участие в олимпиаде
lms_enrollment	lms	учебное зачисление/доступ

organization_student не является универсальным списком всех учеников всех преподавателей. Если самозаявленный преподаватель создаёт свою группу и работает со своими учениками, эти ученики идут через learning_group_participant. Перевод в organization_student возможен только в официальном организационном flow с правами организации.

Минимальные данные:

• фамилия;
• имя;
• отчество, если используется;
• класс;
• буква класса;
• организация;
• статус;
• кто добавил;
• дата создания и изменения.

При добавлении ученика система ищет совпадения внутри организации по normalized full name, классу и букве. Если совпадение найдено, пользователю предлагают выбрать существующую запись. Если это полный тёзка, можно создать отдельную запись с duplicate_note.

Дубли организаций и склейка

При создании организации система показывает похожие организации и предлагает выбрать существующую. Если пользователь всё равно создаёт новую запись при высокой похожести, организация получает duplicate_status = possible_duplicate.

Склейка:

1. системный администратор выбирает основную организацию;
2. выбирает организацию-дубль;
3. система показывает impact preview;
4. администратор подтверждает операцию;
5. связи переносятся в основную организацию;
6. организация-дубль получает status merged;
7. операция пишется в audit.

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

Административный модуль «Систематики»

Админ-модуль обязателен для спорных случаев и ручного управления.

Список организаций:

• поиск;
• фильтр по стране, региону, населённому пункту;
• фильтр по типу, статусу и признаку дубля;
• переход в карточку организации.

Карточка организации:

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

Ручные действия:

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

Все действия системного администратора по организации audit-required.

Интеграции

Competitions

Competitions использует:

• organization;
• organization_student;
• organization_membership;
• organization_team;
• permission context.

Competitions владеет competition_participant, competition_registration, submissions, results и awards. Участие ученика в олимпиаде не является identity-сущностью.

Для official data package competitions обращается к identity protected attributes: СНИЛС ребёнка, дата рождения ребёнка, email родителя и телефон родителя. Если учитель вводит эти данные в разрешённом official flow, identity создаёт protected attribute/contact/invite records; это не выдаёт учителю родительские права.

Task-bank

Task-bank использует organization/team/grant context для доступа к подборкам:

• подборка видна организации;
• подборка видна команде;
• команда может редактировать подборку;
• membership получает resource-level grant.

Task-bank владеет problem, problem_set, problem_usage, attempts и checking.

CRM

CRM может связывать organization с commercial account, person links, invoices, payments и entitlements, но коммерческое владение остаётся CRM.

Management

Management читает organization events и агрегаты для аналитики, но не меняет организации.

MVP и post-MVP

MVP:

• organization;
• country/region/settlement;
• organization reference search;
• membership;
• roles owner, admin, member;
• invitation;
• membership request;
• ownership claim;
• ownership transfer;
• organization student;
• student duplicate detection;
• admin organization list/detail;
• audit.

Post-MVP:

• advanced team permissions;
• resource-level permission grants в UI;
• полный operational flow склейки;
• city directory;
• advanced trust checks;
• franchise-specific roles;
• deep task-bank collection access.

Таблицы под teams, grants и merge можно заложить заранее, даже если UI включается постепенно.

Зафиксированные MVP-решения

Тема	Решение для MVP
Проверка ownership claims	Автоматическая проверка не принимает заявку сама; она только выставляет risk flags. Решение принимает identity admin.
Города и населённые пункты	settlement хранится текстовым полем; отдельный city directory уходит в post-MVP.
Минимальный набор grants	В MVP используются owner, admin, member и catalog permissions из organization_roles.permissions; explicit organization_permission_grant доступен через API/admin только для системного администратора.
Влияние teams на доступ	Teams ограничивают область видимости в organization context, но не создают отдельный top-level actor context.
Различение полных тёзок учеников	MVP хранит grade, class_letter, birth_date при наличии законного основания и duplicate_note; совпадения не склеиваются автоматически.
Owner/author task-bank collection	Task-bank хранит owner/author как собственный source ref, а identity отдаёт только organization/team/membership context и grants.
Видимость audit для владельца организации	Владелец организации видит membership, invitation, student и grant audit без security-sensitive полей; merge, ownership dispute, admin override и security audit видит только системный администратор.

Готовность

• organization_reference не даёт прав;
• organization statuses включают draft, active, unclaimed, disputed, archived, merged;
• membership statuses включают requested, invited, active, rejected, suspended, left;
• ownership claim и transfer описаны в model/schema/API/events;
• organization_student не смешан с student_profile, learning_group_participant и competition_participant;
• самозаявленный преподаватель не получает официальный доступ к организации через educator_profile;
• automatic merge запрещён;
• permissions переведены в catalog format;
• DDL находится только в database-schema.md;
• significant actions пишутся в audit.