Dentolize · Team-Managed Sandbox Config Walkthrough
On this pageThe one-line versionThe problem this PR closesWhat changedWho should read what

Overview

The one-line version

Dentolize's main demo/training sandbox has been deploying with hard-coded defaults — no WhatsApp, no extra environment variables, no way to turn anything on. This PR gives the team a way to configure that sandbox (and any other branch sandbox deployed without a PR) through a GitHub Environment called sandbox, instead of a PR description that doesn't exist for main.

This is an internal CI/DevOps change. It touches one file — .github/workflows/sandbox-ops.yml — and does not change any Dentolize product code, database schema, or clinic-facing feature. Nothing described here is visible to clinics, patients, or pharmacy customers. It's documented here because it changes how the team's own demo, training, and QA environments get configured.

The problem this PR closes

Every Dentolize PR gets an ephemeral preview sandbox. Engineers control that sandbox's behavior — whether WhatsApp is wired up, whether cron/queue run, which environment variables are injected — by editing a ## 🧪 Sandbox YAML block in the PR description (see .github/PULL_REQUEST_TEMPLATE.md). A workflow step parses that block and turns it into a settings file the deploy CLI reads.

main doesn't have a PR. It redeploys straight from git push (.github/workflows/sandbox-main.yml), and until now there was no equivalent place to write whatsapp: true or add a secret for it — so the persistent demo/training sandbox at main.sandbox.anastawfik.com always ran with defaults: no WhatsApp, no two_regions, no custom env.

What changed

sandbox-ops.yml — the manually-triggered workflow used for reseed / reset-data / redeploy / destroy / update-docs operations on any branch's sandbox — now:

  1. Declares environment: sandbox on its job, which grants it read access to a new GitHub Environment named sandbox.
  2. On the redeploy action, runs a new step that reads that environment's flat variables and secrets, picks out the ones prefixed SANDBOX_ALL_ (every branch) or SANDBOX_<REF>_ (one branch, e.g. SANDBOX_MAIN_ for main), and turns them into the exact same JSON shape the PR-body block already produces.
  3. Feeds that JSON into the same deploy path (SANDBOX_SETTINGS_FILE → the sandbox CLI's load_settings) that PR sandboxes already use — so nothing downstream of this step had to change.

The net effect: anyone with write access to the sandbox GitHub Environment can set SANDBOX_MAIN_WHATSAPP=true (a variable), run Actions → Sandbox Ops → redeploy on main, and the demo sandbox comes back up with WhatsApp wired in — no PR required.

Who should read what

  • Walkthrough — what the sandbox looks like before/after this kind of config, with real screenshots.
  • Environment-sourced settings — the prefix scheme, toggles, and how it maps onto the existing PR-body mechanism, with file:line references.
  • Security & guardrails — how secrets are kept out of logs, why github_token can't leak, and the unit-tested compose logic.
  • By-team pages — practical, role-specific notes (support, training, quality, stakeholders, and the honest answer for marketing/sales, who this mostly doesn't touch).