Tempr Docsdocs

2026-05-09 Consultant Release And External Auth Cleanup

Documented the removal of local username/password management, consultant release export on user deletion, and null-safe consultant handling across customers, projects, and the buy flow.

2026-05-09 Consultant Release And External Auth Cleanup

This change updates user lifecycle handling to match the current authentication model and prevents customer or project records from breaking when a consultant account is deleted.

Summary

  • Removed local username and password management from the Filament user admin UI.
  • Kept legacy database compatibility by auto-filling those columns during user creation until the schema is cleaned up.
  • Added user deletion handling that exports consultant ownership data before releasing assignments.
  • Released consultant_id relationships from both customers and projects when a user is deleted.
  • Updated customer portal and notification flows to tolerate consultant_id = null without throwing 500 errors.

Why This Change Exists

Tempr now relies on an external auth server for user authentication. Keeping editable local credentials in the admin UI was misleading and created a maintenance path that no longer reflects how access is granted.

At the same time, user deletion previously conflicted with consultant ownership. Because users are soft-deleted, database-level nullOnDelete() behavior does not run automatically, which left stale consultant_id references behind. Those stale references could trigger runtime errors anywhere the app assumed $customer->consultant or $project->consultant always resolved.

Behavior Changes

User administration

  • The user admin form no longer exposes username or password.
  • User creation still succeeds against the current schema because the model backfills:
    • username from email
    • password with a random hashed value

This preserves compatibility while making it clear that local credentials are not part of the supported workflow.

User deletion

When a user is deleted:

  1. The app gathers all customers assigned through customers.consultant_id.
  2. The app gathers all projects assigned through projects.consultant_id.
  3. It writes an export file to:
storage/app/exports/consultant-releases/
  1. It sets consultant_id to null on both customers and projects.
  2. It stores the export path and release counts in the deleted user's meta payload.

This gives operations a durable record of what was released before those relationships were cleared.

Customer portal and buy flow

The customer-facing proposal and buy-flow views now use fallback branding and contact details when no consultant is assigned. That prevents deleted consultants from causing portal rendering failures.

Fallback behavior currently uses:

  • Name: Shades of Texas
  • Email: support@shadesoftx.com
  • Avatar: /logo/cust/sot_logo.png

Files And Areas Updated

  • app/Models/User.php
  • app/Observers/UserObserver.php
  • app/Support/Users/ReleaseConsultantAssignments.php
  • app/Providers/EventServiceProvider.php
  • app/Filament/Resources/Users/UserResource.php
  • app/Http/Controllers/Customer/LeadRouterController.php
  • resources/views/livewire/customer-portal/v3/proposal-sidebar.blade.php
  • supporting notification and reporting paths that previously assumed a consultant always existed

Operational Notes

  • Customer and project records can now remain valid after consultant deletion.
  • Any code that displays consultant information should continue using null-safe accessors or explicit fallbacks.
  • The export file is written before assignments are released, so it can be used for reassignment audits or manual follow-up.

Verification

Covered by targeted feature tests:

  • tests/Feature/Users/UserDeletionReleasesConsultantAssignmentsTest.php
  • tests/Feature/CustomerPortal/ProposalViewingTest.php