Dentolize · Dynamic Clinic Seeder Walkthrough
On this pageBusiness viewTechnical view

For Support

Business view

Support won't get customer tickets about this — it's internal tooling. But the people who use sandboxes (engineers, QA, sales engineers, reviewers) will ask questions, and they usually land with whoever knows the environment. Here's what they'll ask and how to answer.

"How do I log in to the sandbox?"

Every PR preview posts a comment with the credentials. For a rich (dynamic seed) preview it looks like this:

  • Web and API links.
  • A Clinic user block: email, password, company login name, and a

username (the username works instead of the email).

  • An All clinic logins block: the full staff roster. **Every user shares the

same password.** Log in with a username + the company login name, or with the email.

So if someone says "I can't log in," check:

  1. Are they using the credentials from the latest comment? Redeploys refresh

them.

  1. Are they on a rich preview (has a roster) or a basic one (single

auto-seed user, no roster)? The comment header says which.

  1. Username login needs the company login name too — not just the username.

"Why is the demo clinic different from last time?"

If the sandbox database was wiped and rebuilt, it's a fresh clinic (new random data from the same seed, new company). If it was just redeployed, the seeder recognizes the existing owner and does not rebuild — it only refreshes everyone's password and reprints the credentials. So:

  • Same data, creds refreshed → redeploy (idempotent).
  • All-new data → the volume was wiped.

"The roster names are weird — 'Patient 011 · Insured 50%'."

That's intentional. The sandbox seeds in descriptive mode, where each record's name encodes its configuration so QA can pick a test subject at a glance. It's not a bug. (Marketing captures use realistic names instead.)

"Do these patients/emails belong to real people?"

No. All data is synthetic; emails end in .seed / @example.seed, phone numbers and national IDs are generated. Nothing here is real PII.

"Uploads/images aren't working in the sandbox."

The sandbox uses a self-hosted, S3-compatible file store (MinIO) rather than AWS S3. This PR wires that up via environment variables. If uploads fail in a sandbox, it's an environment-config issue (endpoint / bucket / public URL), not the app — escalate to whoever owns the sandbox infra. Production S3 is unchanged. See S3-compatible uploads.

Technical view

  • Roster + credentials are emitted by the seeder's summary printer as two

machine-readable blocks, SANDBOX_SEED_INFO and SANDBOX_SEED_USERS, which the sandbox CLI parses into the PR comment (report.js:32, report.js:49).

  • Unified password across all users: on a redeploy the seeder resets every

user of the company to the configured password, not just the owner (index.js:78); on first seed everyone is created with the same hash (setupPeople.js:44).

  • Idempotency: if the configured OWNER_EMAIL already exists, the seeder

refreshes passwords, reprints the summary, and returns early instead of building a second company (index.js:71-91).

  • Rich vs basic label: the PR comment branches on SEED_MODE; the dynamic

seeder always reports SEED_MODE=rich (report.js:33, .github/workflows/sandbox.yml).

  • Descriptive names: NAMING=descriptive drives the encoded names

(config.js:75, generate.js:35, setupPeople.js:53).

  • Synthetic PII: generated national IDs, +<dial> phone numbers, .seed

emails (generate.js:48-52).

  • Uploads: the sandbox sets S3_ENDPOINT / S3_FORCE_PATH_STYLE /

S3_PUBLIC_BASE_URL / S3_BUCKET_AWS; when unset, behavior is exactly production AWS (s3.js:60, authMutations.js:1169).