55 lines
3.1 KiB
Markdown
55 lines
3.1 KiB
Markdown
# 🧪 Test Users & Data Scenarios - GoHorseJobs
|
|
|
|
When running the platform locally (via `start.sh`) or on the DEV server (`local.gohorsejobs.com`), the `seeder-api` provisions a rich set of test accounts representing distinct personas.
|
|
|
|
All accounts use the exact same password to simplify development.
|
|
|
|
**Universal Test Password:** `Admin@2025!`
|
|
|
|
---
|
|
|
|
## 👥 Core Personas (The "Golden" Accounts)
|
|
|
|
These are the primary accounts you should use for daily development and E2E testing.
|
|
|
|
| Role | Identifier (Username) | Email | Purpose |
|
|
| :--- | :--- | :--- | :--- |
|
|
| **Superadmin** | `lol` | `lol@gohorsejobs.com` | Complete system access. Bypass company walls. Manage features. |
|
|
| **Superadmin** | `superadmin` | `admin@gohorsejobs.com` | Secondary global admin. |
|
|
| **Admin** | `admin` | `moderator@gohorsejobs.com` | Reviews pending companies/jobs in backoffice. |
|
|
| **Recruiter** | `recruiter` | `hr@techcorp.com` | Posts jobs, manages applicants for "TechCorp" (Company ID: 1). |
|
|
| **Recruiter** | `jane_hr` | `jane.doe@startup.io` | Recruiter for a pending/unapproved company to test gating. |
|
|
| **Candidate** | `candidate` | `carlos.dev@gmail.com` | Standard job seeker. Pre-filled resume and skills. Has 3 active applications. |
|
|
| **Candidate** | `newbie` | `new.user@hotmail.com` | Fresh account with 0 applications and empty profile to test onboarding flows. |
|
|
|
|
---
|
|
|
|
## 🏢 Auto-Generated Companies & Jobs
|
|
|
|
The DB seeder simulates a healthy marketplace.
|
|
If you run `npm run seed:lite`, the DB receives:
|
|
* **50 Companies**: Ranging from "TechCorp" (Active) to "SuspiciousLTDA" (Pending/Rejected).
|
|
* **100 Jobs**: Distributed among the active companies. Various statuses (`published`, `draft`, `closed`).
|
|
* **200 Applications**: Dummy candidates applying to random jobs, in varied pipelines (`pending`, `reviewing`, `accepted`).
|
|
|
|
---
|
|
|
|
## 🚨 Login & Auth "Gotchas"
|
|
|
|
### 1. `Invalid Credentials` Right After Fresh Seed
|
|
If you completely reset the DB using `start.sh` (Option 6) or manually clear Postgres, and your first login returns "Invalid credentials", **do not panic and do not manually change the DB hash**.
|
|
* **Cause**: The Node.js seeder calculates the bcrypt hash using an environment variable called `PASSWORD_PEPPER` (`gohorse-pepper`). If this variable was empty or mismatched with the Backend API, the hash is physically wrong.
|
|
* **Fix**: Ensure your `.env` files in both `backend` and `seeder-api` contain `PASSWORD_PEPPER=gohorse-pepper`. Then simply run `cd seeder-api && npm run seed` again to fix the hashes.
|
|
|
|
### 2. Login Payload Fields
|
|
The frontend sends:
|
|
```json
|
|
{
|
|
"email": "lol",
|
|
"password": "..."
|
|
}
|
|
```
|
|
**Important:** Even though the frontend passes the username `lol`, the JSON key **must** be `"email"`. The Go backend natively handles resolving `"email"` against the `identifier` OR `email` database columns.
|
|
|
|
### 3. Account Status Flags
|
|
The `users` table has an `is_active` boolean. If a user is manually deactivated by an admin, the login endpoint will return a generic `401 Unauthorized` (or specific Account Locked error depending on the exact route version) to prevent user enumeration.
|