28 lines
1.6 KiB
Markdown
28 lines
1.6 KiB
Markdown
# PLAN-employee-list-debug.md
|
|
|
|
## Root Cause Analysis
|
|
I investigated the `EmployeeController@index` method that populates the `/hr/employees` list. The problem is a data mapping gap created by Laravel's strict tenancy architecture.
|
|
|
|
To securely isolate employee lists per company, the controller uses the following strict query scopes:
|
|
```php
|
|
$query = User::with([...])
|
|
->where('created_by', getCompanyAndUsersId())
|
|
->where('type', 'employee');
|
|
```
|
|
When our `ImportLegacyRamesebData` command created the `User` models for every imported employee, we mapped their names, emails, and set `'type' => 'employee'`. However, **we missed setting the `created_by` field** on the `User` model entirely (it was only set on the `Employee` model).
|
|
Because their `created_by` column defaults to `0` or `NULL`, the application correctly assumes they do not belong to your company, and filters them out for security.
|
|
|
|
## Proposed Fixes
|
|
|
|
### 1. Database Patch (To reveal them instantly)
|
|
I will run a quick automated database patch to update the `created_by` column to `1` (which matches your Super Admin/Company ID) for all imported `type = 'employee'` users.
|
|
|
|
### 2. Importer Update
|
|
I will update the `ImportLegacyRamesebData.php` script to ensure:
|
|
- `created_by => 1` is bound to the `User` creation.
|
|
- The Spatie `employee` role is formally assigned to these newly imported users.
|
|
- An `employee_status => 'active'` is explicitly bound to the Employee profile.
|
|
|
|
## Verification
|
|
Once patched, all 10 imported employees should immediately appear on your `/hr/employees` frontend view with their data safely attached.
|