7 commits

Author	SHA1	Message	Date
nns	e8a28ba1f6	feat(employees): двухступенчатое удаление — «уволить» → «удалить» ... Полное физическое удаление сотрудника невозможно — у него FK из retail_sales и supplies. Поэтому теперь два шага: IsActive=true → активный IsActive=false + FiredAt → уволен (кнопка «Уволить») IsActive=false + IsDeleted=true + DeletedAt → удалён (кнопка «Удалить») — Domain: Employee получил поля IsDeleted/DeletedAt + миграция Phase5a_EmployeeSoftDelete (drop column возможен через Down). - API EmployeesController.Delete: · если активен — переводит в Fired; · если уже уволен — ставит IsDeleted=true + DeletedAt; · если уже удалён — 409 Conflict; · гарды Owner и self применяются на ОБОИХ шагах. - API EmployeesController.List: новый query-param ?status= active|fired|deleted|all (default: всё кроме deleted). - DTO дополнен полями isDeleted, deletedAt, status (active/fired/deleted) — фронтэнд использует для бейджа и логики кнопок. - UI EmployeesPage: · фильтр статуса в actions: «Активные и уволенные» (default), «Только активные», «Только уволенные», «Только удалённые», «Все, включая удалённых». · колонка «Статус» теперь с цветным бейджем (emerald/amber/rose). · ФИО уволенного помечается «(уволен)», удалённого — line-through + «(удалён)». · кнопка-действие в модалке: «Уволить» если active, «Удалить» если fired, скрыта если уже deleted (заменена на pojaснение). · confirm-текст обоих шагов разный — юзер понимает что произойдёт. Существующие связанные документы (продажи, поставки) ссылаются на employees по FK; имена для UI берутся из employee.LastName/FirstName + status — отображение «Иванов И.И. (удалён)» работает автоматически.	2026-05-06 11:32:07 +05:00
nns	b073e99ca7	feat(roles): три системные роли — Admin/Cashier/Storekeeper ... Менеджер/Закупщик/Бухгалтер сидились как кастомные шаблоны вместе с организацией, но при этом числились системными в DevDataSeeder (IsSystem=false), что путало UI (где-то нельзя было менять, где-то можно было). Юзер хочет: при создании новой орги только три системные роли (Admin, Storekeeper, Cashier), все остальные роли администратор создаёт сам. — SystemRoles.Manager убран. Identity-роли сидируются: SuperAdmin, Admin, Cashier, Storekeeper. — EmployeeRoles tenant-сидер создаёт только три записи (все IsSystem=true, все три не редактируются и не удаляются обычным юзером — это правило уже работало для Админа/Кассира, теперь покрывает Кладовщика). — Authorize(Roles = ".. Manager ..") убрано из всех контроллеров (13 файлов): Sales/RetailSales, Catalog/{Products,ProductImages,ProductGroups, Counterparties,UnitsOfMeasure,RetailPoints,PriceTypes,Stores}, Purchases/Supplies, Organizations/{Employees,EmployeeRoles, OrganizationSettings}. Существующие организации с уже созданными «Менеджер/Закупщик/ Бухгалтер» записями НЕ затрагиваются — сидер пропускает org если в ней уже есть роли (anyRole short-circuit). При желании админ может удалить эти кастомные роли через UI.	2026-05-06 11:31:15 +05:00
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	2691b7d78b	feat(employees): бейдж «Владелец» + блокировка удаления с объяснением ... Жалоба юзера: «нажимаю удалить владельца магазина — диалог "удалить сотрудника?" — нажимаю — ничего не происходит». Раньше кнопка «Удалить» для Owner была доступна, на сервере отвечала 403 с понятным сообщением, но фронт ошибку не ловил — модалка зависала. — EmployeeDto теперь возвращает isOwner (Org.AccountOwnerUserId == Employee.UserId) и isSelf (UserId текущего залогиненного юзера). List + Get обновлены: подгружают AccountOwnerUserId и текущий sub из JWT, проставляют флаги в проекции. — Таблица сотрудников: рядом с ФИО владельца — бейдж «Владелец» (amber-100/800). — Кнопка «Удалить» в модалке редактирования: · disabled для Owner и для self с tooltip-объяснением; · клик по disabled-кнопке через onClick-handler показывает спец- модалку: «Нельзя удалить владельца магазина — сначала передайте управление другому пользователю. Организация не может остаться без владельца. Удалить или деактивировать саму организацию может только Супер-администратор платформы.»; · self-delete объясняется отдельным текстом (Настройки → Аккаунт → Покинуть организацию); · обычное удаление — confirm с именем сотрудника и пояснением что это soft-delete (деактивация). · 403/любая ошибка от сервера ловится в try/catch и показывается в той же модалке «Не удалось удалить» — больше не «ничего не происходит». Smoke: API эмплоя возвращает isOwner=true,isSelf=false для Owner'а в override-режиме SuperAdmin'а.	2026-04-27 18:58:08 +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
nns	bf6880fe0f	feat(employee): add Salary, TaxNumber, Description, ImageUrl + radio role picker ... Domain Employee расширен 4 nullable-полями (по образу сторонняя система): - Salary numeric(18,2) — оклад в валюте организации - TaxNumber varchar(20) — ИИН/ИНН - Description varchar(2000) — комментарий HR'а - ImageUrl varchar(500) — аватар (на будущее: загрузка через images endpoint как у товаров; пока поле для прямой ссылки) Migration Phase4c_EmployeeExtraFields добавляет 4 nullable колонки (существующие записи не ломаются). EF config + snapshot обновлены. API EmployeesController: DTO/Input/Create/Update пробрасывают новые поля сквозь. Frontend EmployeesPage: - Поля «Оклад» и «ИИН/ИНН» рядом, ниже — «Описание» textarea. - Селект роли заменён на radio-список с описанием каждой роли (системные сначала, затем кастомные). Под радио — ссылка «Настроить права ролей →» на /settings/employee-roles. Это по образу МС — пользователь сразу видит за что отвечает каждая роль и куда идти если нужно подкрутить. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-26 12:48:27 +05:00
nns	c714ec265c	feat(api): EmployeesController + EmployeeRolesController + invite-with-temp-password ... EmployeeRolesController (/api/organization/employee-roles): - List/Get/Create/Update/Delete. Системные роли (IsSystem=true) — нельзя удалить (409), но имя/описание/permissions редактируются (чтобы можно было кастомизировать набор галок). Удаление 409 если роль уже используется сотрудниками. EmployeesController (/api/organization/employees): - List с поиском по фамилии/имени/email/телефону. - Create: - LastName, FirstName, MiddleName, Position, Email, Phone, RoleId, IsActive - RetailPointIds[] — для роли Кассир привязка к нескольким кассам; хранится в employee_retail_point_assignments. - CreateAccount=true → одновременно создаём User (Identity) с email и случайным temp-паролем (12 символов, все классы), возвращаем в response.GeneratedPassword один раз — UI покажет «выдайте сотруднику». - Update — replace assignments wholesale; IsActive false → проставляем FiredAt=now (восстановление обнуляет). - Delete — без проверок на FK документов (на этом этапе нет других ссылок на Employee, кроме CASCADE-связи с retail-point assignments). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-26 12:03:39 +05:00