autocrm

Vasyka/autocrm

Fork 0

Commit Graph

Author	SHA1	Message	Date
Vasyka	1d4ac3db38	feat: P1 RBAC defers — overrides + sessions + audit log Completes the P1 items from /tmp/service/new/01-TZ-rbac §2.1 §4.1. == user_permission_overrides table == Per-user grant/deny exceptions on top of role-based RBAC. Composite PK (user_id, permission_id) so each user can have at most one override per permission. Schema: - mode: 'grant' \| 'deny' - reason: text (audit context: "lockdown audit period", etc.) - granted_by_id + granted_at: who/when made the exception - expires_at: optional auto-expiry Eloquent model UserPermissionOverride with relations to user, permission, grantedBy; isExpired() helper. == Resolution order in User::canDo() == 1. Active deny-override (not expired) → return false (and log if sensitive) 2. Active grant-override (not expired) → return true 3. Admin/owner bypass → return true 4. Standard role-based check via Spatie Critically: deny overrides ALSO block admin/owner. This is intentional — the TZ's "separation of duties" requirement (an admin who shouldn't be able to delete payments). Without this, deny is useless against admins. Override resolution uses a single query per check (cached by Eloquent during the request). The override-check happens before the role check so a deny is always authoritative. == Audit log on sensitive denials == When canDo() returns false for one of these sensitive permissions, a spatie/activitylog entry is written with event=permission_denied: - admin.users.manage / admin.roles.manage / admin.settings.edit / admin.backup.download - finance.delete_payment / finance.view_pl - salaries.mark_paid / salaries.view_all - work_orders.delete / work_orders.approve_discount_any Non-sensitive denials (e.g., clients.create) don't log to avoid noise. The activity payload includes the permission slug; causedBy is the user who was denied. Failures of the logger are swallowed so a misconfigured activitylog never breaks auth. == UserResource UI == New PermissionOverridesRelationManager mounted on the edit page: - Table: permission, mode (GRANT/DENY badge), reason, expires_at, granted_by - Create form: permission select, mode, expires_at, reason - granted_at + granted_by_id auto-populated to now() / auth()->id() - Default sort: granted_at desc Two new actions on the user row: - "Force logout" (warning color): visible only when active sessions exist. Deletes every row in `sessions` with user_id=record→id. Notification shows count revoked. - "Resetează 2FA" stays (from previous commit) Two new toggleable columns: - Sesiuni active (count from sessions table) - Excepții (count of permission overrides) == Tests == PermissionOverridesTest covers: - grant unlocks a permission the role doesn't have - deny blocks a permission the role grants - deny blocks even admin role (separation of duties) - expired override is ignored - future-expiry override stays active - audit log writes on sensitive denial - audit log silent on non-sensitive denial - force_logout deletes all user sessions but not others' Suite: 214 passed (591 assertions). Was 206. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-06-04 22:27:20 +00:00
Vasyka	58004b65c4	feat: RBAC catalog + 2FA UX (P0 blocker from /tmp/service/new/01-TZ) Implements the RBAC TZ in app/Auth/Permissions.php with a 51-permission catalog spanning 9 modules (clients/vehicles/work_orders/finance/salaries/ inventory/suppliers/admin/ai_assistant+analytics). All slugs are constants, not magic strings — refactors against renames stay safe. == 7 system roles == owner / admin / manager / accountant / receptionist / mechanic / viewer Each gets a curated role-permission matrix per the TZ section 2.4: - owner + admin: all 51 - manager: 23 (operations + reporting, no destructive finance/users) - accountant: 17 (full finance/salaries, view-only WOs, no admin) - receptionist: 13 (front-desk: clients/vehicles/WOs/payment-create) - mechanic: 4 (own WOs + inventory view + own salary) - viewer: 6 (read-only everything except finance/salaries) == Seeder == App\Services\RbacSeeder: - seedPermissions() creates the 51 Permission rows globally (idempotent) - seedTenantRoles($companyId) sets the team context, creates the 7 Role rows scoped to that tenant, and syncPermissions per matrix - syncUsersToRoles($companyId) maps legacy users.role string column to the new Spatie role assignment (parts_manager→manager, master→mechanic, marketer→manager, user→viewer) == Migration == 2026_06_04_000003 loops over all existing Companies and runs the seeder. On a fresh prod deploy, every tenant gets the full RBAC catalog wired up automatically. CompanyProvisioner::provision() also calls the seeder for new tenants going forward. == Resource gates == canViewAny / canCreate / canDelete on: - PaymentResource (FINANCE_VIEW_OVERVIEW / FINANCE_CREATE_PAYMENT / FINANCE_DELETE_PAYMENT) - ExpenseResource (FINANCE_VIEW_OVERVIEW / FINANCE_CREATE_EXPENSE / FINANCE_DELETE_PAYMENT) - PayrollAdjustmentResource (SALARIES_VIEW_ALL / SALARIES_CALCULATE) - PayrollRunResource (SALARIES_VIEW_ALL / SALARIES_CALCULATE) - UserResource (ADMIN_USERS_VIEW / ADMIN_USERS_MANAGE) - RoleResource (ADMIN_ROLES_MANAGE) Mechanic sees only own WOs + inventory + own salary. Accountant sees all finance but not admin. Receptionist sees clients/WOs but not finance overview. Etc. == User helpers == $user->canDo(Permissions::WORK_ORDERS_CREATE) — admin gets a bypass to prevent lockouts from misconfigured permission grants. $user->isOwner() / isAccountant() / isMechanic() — role shortcuts. $user->hasTwoFactorEnabled() — true when app_authentication_secret is set. == 2FA == Filament 5's native MultiFactorAuthentication (App + Email) is already enabled in both TenantPanelProvider and CentralPanelProvider — confirmed. The User model already implements HasAppAuthentication + HasAppAuthenticationRecovery + HasEmailAuthentication. This commit adds UX around it: - UserResource list column: 2FA badge (green ✓ when enabled, amber ⚠ when off) - UserResource form: "Securitate" section shows enabled/disabled + last_login_at - New admin action "Resetează 2FA" with confirmation modal — clears app_authentication_secret + recovery codes for locked-out users == Roles management UI == New /app/roles RoleResource: - List: role label + slug + permission count + user count - Edit: 10 grouped checkbox lists (per module) for fine-grained permission assignment + bulk-toggle per group - System roles (owner/admin/etc.) have slug locked, can't be deleted - Custom tenant-specific roles can be added on top - Gated behind ADMIN_ROLES_MANAGE == UserResource extension == - Role select now uses Permissions::roleLabels() (owner/admin/manager/...) - New "Roluri suplimentare" multi-select for stacking roles on top of the primary one (permissions cumulate) - afterSave syncs the picked roles + ensures primary role is always included == Tests == RbacTest covers: 51 permissions seeded, 7 roles per tenant, owner has all, mechanic has minimal, accountant has finance but not admin, canDo returns true when role has permission, admin bypass, owner helper, syncUsersToRoles legacy mapping (parts_manager→manager, master→mechanic, user→viewer), 2FA helper round-trip. Suite: 206 passed (576 assertions). Was 196. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-06-04 22:03:03 +00:00
Vasyka	c9cb3560ef	Faza 3.1: CRM core — Leads, Deals, Appointments, Settings, Widgets, Users Spatie Permission cu teams (team_foreign_key=company_id, teams=true): - migrations create_permission_tables (model_has_roles cu company_id scope) - HasRoles trait pe User - ResolveTenant middleware setează permissions team_id la tenant.id - Seed: 7 roluri default per tenant (admin/manager/receptionist/mechanic/parts_manager/accountant/marketer) Module noi: - Leads (cereri): name, phone, car/model, source, UTM, status, budget, assigned_to, acțiune "Convertește" → creează automat Client + Deal - Deals (pipeline): client/vehicle, stage (8 stage-uri), price, source, lost_reason - Posts + Appointments: post_id (boxă), master_id, date+time_start+time_end, status, color - UserResource (tenant): CRUD users cu role/status/locale; canViewAny doar pentru admin Custom Filament page "Setări" (tenant): - Brand & contact (display_name, city, phone, email) - Localizare (limba RO/RU/EN, currency, theme color picker) - Servicii & tarif (labor_rate) - Liste configurabile (services, cars) — păstrate în companies.settings JSON Widgets dashboard: - Tenant: StatsOverview (Clienți, Mașini, Cereri noi, Deal-uri active, Programări azi) - Central: PlatformStats (Companii total/active/trial, Expiră în 7 zile) Seed extins demo PSauto: - 3 posturi (Pod 1/2/3 cu culori) - 2 lead-uri demo (Alex Grosu Telegram, Irina Cojocaru WhatsApp) - 3 deal-uri demo (BMW done, Audi in_work, Porsche agree) - 2 programări (azi + mâine) Filament v5 fixes: - $navigationGroup type → string\|UnitEnum\|null (parent stricter signature) - Toate resources noi au tipurile corecte	2026-05-06 17:36:32 +00:00

Author

SHA1

Message

Date

Vasyka

1d4ac3db38

feat: P1 RBAC defers — overrides + sessions + audit log

Completes the P1 items from /tmp/service/new/01-TZ-rbac §2.1 §4.1.

== user_permission_overrides table ==
Per-user grant/deny exceptions on top of role-based RBAC. Composite PK
(user_id, permission_id) so each user can have at most one override per
permission. Schema:
- mode: 'grant' | 'deny'
- reason: text (audit context: "lockdown audit period", etc.)
- granted_by_id + granted_at: who/when made the exception
- expires_at: optional auto-expiry

Eloquent model UserPermissionOverride with relations to user, permission,
grantedBy; isExpired() helper.

== Resolution order in User::canDo() ==
1. Active deny-override (not expired) → return false (and log if sensitive)
2. Active grant-override (not expired) → return true
3. Admin/owner bypass → return true
4. Standard role-based check via Spatie

Critically: deny overrides ALSO block admin/owner. This is intentional —
the TZ's "separation of duties" requirement (an admin who shouldn't be
able to delete payments). Without this, deny is useless against admins.

Override resolution uses a single query per check (cached by Eloquent
during the request). The override-check happens before the role check
so a deny is always authoritative.

== Audit log on sensitive denials ==
When canDo() returns false for one of these sensitive permissions, a
spatie/activitylog entry is written with event=permission_denied:
- admin.users.manage / admin.roles.manage / admin.settings.edit
  / admin.backup.download
- finance.delete_payment / finance.view_pl
- salaries.mark_paid / salaries.view_all
- work_orders.delete / work_orders.approve_discount_any

Non-sensitive denials (e.g., clients.create) don't log to avoid noise.
The activity payload includes the permission slug; causedBy is the user
who was denied. Failures of the logger are swallowed so a misconfigured
activitylog never breaks auth.

== UserResource UI ==
New PermissionOverridesRelationManager mounted on the edit page:
- Table: permission, mode (GRANT/DENY badge), reason, expires_at,
  granted_by
- Create form: permission select, mode, expires_at, reason
- granted_at + granted_by_id auto-populated to now() / auth()->id()
- Default sort: granted_at desc

Two new actions on the user row:
- "Force logout" (warning color): visible only when active sessions
  exist. Deletes every row in `sessions` with user_id=record→id.
  Notification shows count revoked.
- "Resetează 2FA" stays (from previous commit)

Two new toggleable columns:
- Sesiuni active (count from sessions table)
- Excepții (count of permission overrides)

== Tests ==
PermissionOverridesTest covers:
- grant unlocks a permission the role doesn't have
- deny blocks a permission the role grants
- deny blocks even admin role (separation of duties)
- expired override is ignored
- future-expiry override stays active
- audit log writes on sensitive denial
- audit log silent on non-sensitive denial
- force_logout deletes all user sessions but not others'

Suite: 214 passed (591 assertions). Was 206.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-06-04 22:27:20 +00:00

Vasyka

58004b65c4

feat: RBAC catalog + 2FA UX (P0 blocker from /tmp/service/new/01-TZ)

Implements the RBAC TZ in app/Auth/Permissions.php with a 51-permission
catalog spanning 9 modules (clients/vehicles/work_orders/finance/salaries/
inventory/suppliers/admin/ai_assistant+analytics). All slugs are constants,
not magic strings — refactors against renames stay safe.

== 7 system roles ==
owner / admin / manager / accountant / receptionist / mechanic / viewer
Each gets a curated role-permission matrix per the TZ section 2.4:
- owner + admin: all 51
- manager: 23 (operations + reporting, no destructive finance/users)
- accountant: 17 (full finance/salaries, view-only WOs, no admin)
- receptionist: 13 (front-desk: clients/vehicles/WOs/payment-create)
- mechanic: 4 (own WOs + inventory view + own salary)
- viewer: 6 (read-only everything except finance/salaries)

== Seeder ==
App\Services\RbacSeeder:
- seedPermissions() creates the 51 Permission rows globally (idempotent)
- seedTenantRoles($companyId) sets the team context, creates the 7 Role
  rows scoped to that tenant, and syncPermissions per matrix
- syncUsersToRoles($companyId) maps legacy users.role string column to
  the new Spatie role assignment (parts_manager→manager, master→mechanic,
  marketer→manager, user→viewer)

== Migration ==
2026_06_04_000003 loops over all existing Companies and runs the seeder.
On a fresh prod deploy, every tenant gets the full RBAC catalog wired up
automatically. CompanyProvisioner::provision() also calls the seeder for
new tenants going forward.

== Resource gates ==
canViewAny / canCreate / canDelete on:
- PaymentResource (FINANCE_VIEW_OVERVIEW / FINANCE_CREATE_PAYMENT / FINANCE_DELETE_PAYMENT)
- ExpenseResource (FINANCE_VIEW_OVERVIEW / FINANCE_CREATE_EXPENSE / FINANCE_DELETE_PAYMENT)
- PayrollAdjustmentResource (SALARIES_VIEW_ALL / SALARIES_CALCULATE)
- PayrollRunResource (SALARIES_VIEW_ALL / SALARIES_CALCULATE)
- UserResource (ADMIN_USERS_VIEW / ADMIN_USERS_MANAGE)
- RoleResource (ADMIN_ROLES_MANAGE)

Mechanic sees only own WOs + inventory + own salary. Accountant sees all
finance but not admin. Receptionist sees clients/WOs but not finance
overview. Etc.

== User helpers ==
$user->canDo(Permissions::WORK_ORDERS_CREATE) — admin gets a bypass to
prevent lockouts from misconfigured permission grants.
$user->isOwner() / isAccountant() / isMechanic() — role shortcuts.
$user->hasTwoFactorEnabled() — true when app_authentication_secret is set.

== 2FA ==
Filament 5's native MultiFactorAuthentication (App + Email) is already
enabled in both TenantPanelProvider and CentralPanelProvider — confirmed.
The User model already implements HasAppAuthentication +
HasAppAuthenticationRecovery + HasEmailAuthentication.

This commit adds UX around it:
- UserResource list column: 2FA badge (green ✓ when enabled, amber ⚠ when off)
- UserResource form: "Securitate" section shows enabled/disabled + last_login_at
- New admin action "Resetează 2FA" with confirmation modal — clears
  app_authentication_secret + recovery codes for locked-out users

== Roles management UI ==
New /app/roles RoleResource:
- List: role label + slug + permission count + user count
- Edit: 10 grouped checkbox lists (per module) for fine-grained
  permission assignment + bulk-toggle per group
- System roles (owner/admin/etc.) have slug locked, can't be deleted
- Custom tenant-specific roles can be added on top
- Gated behind ADMIN_ROLES_MANAGE

== UserResource extension ==
- Role select now uses Permissions::roleLabels() (owner/admin/manager/...)
- New "Roluri suplimentare" multi-select for stacking roles on top of
  the primary one (permissions cumulate)
- afterSave syncs the picked roles + ensures primary role is always
  included

== Tests ==
RbacTest covers: 51 permissions seeded, 7 roles per tenant, owner has
all, mechanic has minimal, accountant has finance but not admin,
canDo returns true when role has permission, admin bypass, owner helper,
syncUsersToRoles legacy mapping (parts_manager→manager, master→mechanic,
user→viewer), 2FA helper round-trip.

Suite: 206 passed (576 assertions). Was 196.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-06-04 22:03:03 +00:00

Vasyka

c9cb3560ef

Faza 3.1: CRM core — Leads, Deals, Appointments, Settings, Widgets, Users

Spatie Permission cu teams (team_foreign_key=company_id, teams=true):
- migrations create_permission_tables (model_has_roles cu company_id scope)
- HasRoles trait pe User
- ResolveTenant middleware setează permissions team_id la tenant.id
- Seed: 7 roluri default per tenant (admin/manager/receptionist/mechanic/parts_manager/accountant/marketer)

Module noi:
- Leads (cereri): name, phone, car/model, source, UTM, status, budget, assigned_to,
  acțiune "Convertește" → creează automat Client + Deal
- Deals (pipeline): client/vehicle, stage (8 stage-uri), price, source, lost_reason
- Posts + Appointments: post_id (boxă), master_id, date+time_start+time_end, status, color
- UserResource (tenant): CRUD users cu role/status/locale; canViewAny doar pentru admin

Custom Filament page "Setări" (tenant):
- Brand & contact (display_name, city, phone, email)
- Localizare (limba RO/RU/EN, currency, theme color picker)
- Servicii & tarif (labor_rate)
- Liste configurabile (services, cars) — păstrate în companies.settings JSON

Widgets dashboard:
- Tenant: StatsOverview (Clienți, Mașini, Cereri noi, Deal-uri active, Programări azi)
- Central: PlatformStats (Companii total/active/trial, Expiră în 7 zile)

Seed extins demo PSauto:
- 3 posturi (Pod 1/2/3 cu culori)
- 2 lead-uri demo (Alex Grosu Telegram, Irina Cojocaru WhatsApp)
- 3 deal-uri demo (BMW done, Audi in_work, Porsche agree)
- 2 programări (azi + mâine)

Filament v5 fixes:
- $navigationGroup type → string|UnitEnum|null (parent stricter signature)
- Toate resources noi au tipurile corecte

2026-05-06 17:36:32 +00:00

3 Commits