task-l.1

docs/implementation/task-l1-crm-multi-role-user-assignment.md

@@ -0,0 +1,46 @@
+# Task L.1: CRM Multi-Role User Assignment
+
+## Summary
+
+Task L.1 extends the CRM authorization foundation so one user can hold multiple CRM role assignments inside the same organization.
+
+## Implemented
+
+- Added `crm_user_role_assignments` schema for CRM-specific authorization rows
+- Added assignment permissions:
+  - `crm.role.assignment.read`
+  - `crm.role.assignment.create`
+  - `crm.role.assignment.update`
+  - `crm.role.assignment.delete`
+  - `crm.role.assignment.manage`
+- Added lazy compatibility backfill from `memberships.businessRole` into CRM role assignments
+- Updated CRM access resolution to:
+  - union permissions across all active assignments
+  - union branch/product scope across assignments
+  - choose the most permissive ownership scope
+  - choose the highest approval authority
+  - use primary role for display only
+- Added `CRM Settings > User Role Assignments`
+- Added assignment API routes:
+  - `GET /api/crm/settings/user-role-assignments`
+  - `POST /api/crm/settings/user-role-assignments`
+  - `PATCH /api/crm/settings/user-role-assignments/[id]`
+  - `DELETE /api/crm/settings/user-role-assignments/[id]`
+- Added audit logging for `crm_user_role_assignment`
+- Added ADR `0014-crm-multi-role-user-assignment`
+
+## Compatibility
+
+- `memberships.businessRole` remains in place
+- when no active CRM role assignment exists, resolver still falls back safely
+- when role assignments exist, CRM authorization no longer treats `memberships.businessRole` as the primary source
+
+## Verification
+
+- Run: `npx tsc --noEmit`
+
+## Remaining Risks
+
+- user-creation and user-edit flows still center around legacy `memberships.businessRole`
+- some CRM modules beyond the current resolver consumers may still need deeper scenario verification with mixed-role fixtures
+- a dedicated one-shot operational migration script can still be useful even though lazy backfill is active