2 commits

Author	SHA1	Message	Date
nns	c0824518ab	feat(employees): главный администратор — терминология + защита роли/активности ... — «Владелец» переименован в «Главный администратор» — терминологически у нас не «собственник», а тот кто управляет организацией. Бейдж в таблице, тексты модалок, серверные сообщения 403 — везде единая формулировка. — PUT /api/organization/employees/{id}: добавлен гард для главного администратора: · Смена RoleId на не-«Администратор» → 403 «Нельзя сменить роль…» · IsActive=false → 403 «Нельзя деактивировать…» Раньше юзер мог поменять себе роль на Кладовщик и получить бейдж «Владелец» с ролью кладовщика — несостыковка. — EmployeesPage: при редактировании главного администратора · Селект ролей disabled + amber-плашка-объяснение «роль фиксирована» · Чекбокс «Активен» disabled + текст «нельзя деактивировать» · save() ловит ошибки и показывает их в общей модалке (раньше 403 «тихо проваливалось» — модалка зависала). — recovery-restore-orphan-owners.sql добавлен блок: для всех Organizations где главный администратор имеет роль не-«Администратор» или IsActive=false → восстанавливает «Администратор» и активирует. Идемпотентен. Применён на стейдже (0 пострадавших — текущая БД ОК). Все изменения главного администратора (роль, ФИО, удаление, передача управления) по архитектурному решению юзера должны идти через очередь запросов к Супер-администратору платформы. Эта подсистема — отдельная большая фича (RequestType / RequestQueue / SuperAdmin approval UI), её план описан в TG-ответе.	2026-04-27 19:12:33 +05:00
nns	633bdf3ef0	fix(auth): закрыть критические дыры — orphan login, self-delete, owner-delete, override-баннер ... Аудит 2026-04-27. Полный отчёт — docs/audit-2026-04-27.md. Что закрыто: — /connect/token (AuthorizationController) теперь отказывает в login если AppUser привязан к удалённой/архивной Organization. SuperAdmin обходит проверку (ему org не нужна). Жалоба: nurnetps@gmail.com мог логиниться после удаления своей org из SuperAdmin консоли. — SuperAdminOrganizationsController.Delete (DELETE org) каскадно деактивирует всех AppUser привязанных к этой org (IsActive=false, OrganizationId=null) и помечает Status='revoked' для всех их OpenIddictTokens. Раньше Org удалялась, а юзеры оставались валидными с активными refresh-tokens на 30 дней. — EmployeesController.Delete теперь soft-delete (IsActive=false, FiredAt). Запрещены: 403 если попытка удалить себя; 403 если попытка удалить Owner (Organization.AccountOwnerUserId == employee.UserId). Сообщения с инструкцией («передайте права», «покинуть через настройки»). — /api/me возвращает hasLiveOrg и hasActiveEmployee — frontend использует это для редиректа на /no-organization вместо белого экрана. — Новая страница /no-organization (NoOrganizationPage) — fallback для orphan AppUser. CTA: создать новую org через публичный /signup или попросить инвайт. Кнопка «выйти». TenantRouteGuard редиректит orphan юзеров туда. — SuperAdminAsOrgBanner: добавлена проверка через useMe — баннер рендерится только если у текущего юзера есть Identity-роль SuperAdmin. Lingering localStorage override от прошлой сессии (другой юзер логинился до этого) автоматически чистится. — auth.ts: clearTokens() теперь сбрасывает superAdminAsOrg и superAdminEditMode. login() вызывает clearTokens() ПЕРЕД запросом чтобы новый юзер не унаследовал override-состояние от предыдущего. — deploy/recovery-restore-orphan-owners.sql — идемпотентный скрипт деактивирующий уже накопленных orphan AppUser (как nurnetps) и revoke их токены. Применён на стейдже: 1 user деактивирован, 9 токенов revoked. — deploy/Dockerfile.api: убран `--no-restore` из publish — два раздельных шага роняли build с NETSDK1064 на свежих analyzer- зависимостях, теперь restore идёт внутри publish. Smoke (стейдж): - nurnetps@gmail.com /connect/token → invalid_grant. - admin@food-market.local /connect/token → access_token выдан. - food-market.zat.kz/, /signup/, app.../login, /health → 200.	2026-04-27 09:28:18 +05:00