Единая target-aware policy can_manage_employee(actor, target, action) и can_create_role
(governance.py) по матрице SPEC-HUB-0016 §8: OWNER управляет ADMIN и EMPLOYEE, ADMIN —
только EMPLOYEE, смена роли и передача владения — только OWNER.
Роль ADMIN активирована: is_manager/IsManager, обычные capability уровня организации
открыты OWNER и ADMIN (каналы, AI, интеграции, продукты, заказы, корректировки продаж,
контракты поддержки, командный центр, звонки, уведомления). Governance-действия над
привилегированными целями остаются за OWNER.
Employee endpoints переведены на governance: create ADMIN/EMPLOYEE по policy, update
делит проверки profile/role/placement, block/unblock/reset/terminate — через
can_manage_employee с аудитом отказа. Новый атомарный OwnershipTransferView сохраняет
инвариант ровно одного владельца (понижение прежнего перед промоутом, row-lock).
Аудит по SPEC-HUB-0016 §16; payload отдаёт per-actor permissions.
Frontend: ADMIN получает доступ уровня владельца (access.ts + тесты), действия над
сотрудником скрываются по backend permissions. UI передачи владения не проектируется
до утверждения design gate (SPEC-HUB-0016 §14).
Проверено полным backend-suite в Docker (293 tests, OK), typecheck и vitest.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- DRF defaults: SessionAuthentication, IsAuthenticated, JSON-only render/parse
- shared api package: IsOwner permission (audits denials) and an exception
handler that flattens every error body to the {detail} SPA contract
- products views rewritten as APIView with permission_classes; manual JSON
parsing and auth checks removed (DRF parser returns 400 on bad JSON)
- response shapes and status codes preserved; product tests use DRF APIClient
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Andrey