74 lines
3.7 KiB
Markdown
74 lines
3.7 KiB
Markdown
# Demo Accesses and Email Domain
|
|
|
|
## Goal
|
|
|
|
Make the demo credentials easy to use and standardize the platform demo accounts
|
|
from `@agendapro.demo` to `@agendamax.demo` in source data, documentation, local
|
|
data, and the deployed Coolify instance.
|
|
|
|
## Scope
|
|
|
|
- Replace active positive `@agendapro.demo` references in application code,
|
|
tests, README, and operational documentation with `@agendamax.demo`; retain
|
|
the old domain only in migration-history documentation or explicit
|
|
negative-login assertions.
|
|
- Keep the existing demo password `demo1234` and expose it clearly beside each
|
|
demo account in `README.md`.
|
|
- Update the local SQLite demo users without deleting businesses, appointments,
|
|
or other seeded records.
|
|
- Deploy the code to the existing AgendaMax Coolify application.
|
|
- Update the persistent production SQLite users for the exact admin and owner
|
|
accounts with a targeted SQL change, preserving all other data.
|
|
|
|
## Data Flow
|
|
|
|
Fresh databases receive the new admin and owner emails from `server/scripts/seed.ts`
|
|
and `server/index.ts`. Existing local and production databases are migrated by
|
|
updating only these two exact rows: `[email protected]` and
|
|
`[email protected]`. If the active database is fresh and already contains the
|
|
new emails, the SQL update is a no-op and is skipped.
|
|
|
|
The employee accounts already use their business domains and are not changed.
|
|
Login verification uses `POST /api/auth/login` with the documented password and
|
|
does not expose password values through the API.
|
|
|
|
## Production Procedure
|
|
|
|
1. Run the local checks and build.
|
|
2. Push the change to the AgendaMax source mirror used by Coolify.
|
|
3. Trigger and monitor a Coolify deployment.
|
|
4. Inspect the exact old/new admin and owner rows. If an old row and its matching
|
|
new row both exist, stop and resolve the unique-email collision. If no old
|
|
rows exist and the new rows are present, record a safe no-op. Otherwise run a
|
|
targeted SQLite update inside the persistent production app volume:
|
|
`UPDATE users SET email = CASE email WHEN '[email protected]' THEN '[email protected]' WHEN '[email protected]' THEN '[email protected]' END WHERE (email = '[email protected]' AND role = 'admin') OR (email = '[email protected]' AND role = 'owner');`
|
|
5. Verify health, login for admin and owner, and the production page.
|
|
|
|
If deployment fails, do not run the production SQL migration; inspect the
|
|
deployment first and use the existing Coolify rollback procedure.
|
|
|
|
## Acceptance Criteria
|
|
|
|
- `rg "agendapro\.demo"` returns no active positive application, test, or
|
|
README references; only explicit negative-login assertions and
|
|
migration-history documentation may retain the old domain.
|
|
- README lists every demo account with email and `demo1234`.
|
|
- Fresh seed creates `[email protected]` and `[email protected]`.
|
|
- Existing local data contains the new emails and retains its records.
|
|
- Coolify deployment finishes successfully.
|
|
- Production `/api/health` returns `ok: true`.
|
|
- Production admin and owner logins succeed with `demo1234`.
|
|
- Production admin and owner logins using the old domain return `401`.
|
|
- README employee emails exactly match the accent-preserving emails generated by the seed.
|
|
- The targeted SQL pairs each old email with its matching role and never rewrites
|
|
another old-domain user.
|
|
|
|
## Known Verification Limitation
|
|
|
|
The already-migrated local database has null `businesses.working_hours` and
|
|
employee `working_hours` values. As a result, the slot-dependent `test:e2e` and
|
|
`test:booking` assertions can fail before booking, including their existing
|
|
downstream dereference. This is a pre-existing scheduling-data limitation,
|
|
unrelated to the email-domain change; do not change working-hours data for this
|
|
task.
|