@dooer/dooer-test-env 1.15.0 → 1.17.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dooer/dooer-test-env",
-  "version": "1.15.0",
+  "version": "1.17.0",
   "description": "Run the whole Dooer backend locally (staging DB minus customers), copy/purge customers between environments, and shred — one CLI.",
   "license": "UNLICENSED",
   "repository": "Dooer/cli-dooer-test-env",

package/readme.md

@@ -6,7 +6,8 @@ organizations). Copy specific customers in when you need them, spin up empty tes
 across the whole stack, and measure resource usage.
 
 Runs on an Apple-Silicon Mac (images run under emulation) — 32 GB RAM / ~150 GB free disk is comfortable.
-See **[ENVIRONMENT-PLAN.md](./ENVIRONMENT-PLAN.md)** for the full design and rationale.
+See **[ENVIRONMENT-PLAN.md](./ENVIRONMENT-PLAN.md)** for the full design and rationale, and
+**[REVERT-POINT.md](./REVERT-POINT.md)** for the last version that works without `service-dooer-test-env`.
 
 ```bash
 npx @dooer/dooer-test-env <command>
@@ -14,21 +15,32 @@ npx @dooer/dooer-test-env <command>
 
 ## First time here?
 
-`setup` needs **VPN access** and a **kubectl credential** for the cluster — the compose file, the registry
-logins and the BankID cert all come from there.
+You need exactly two things:
 
-- **[Getting access](./docs/getting-access.md)** — new developer: set up the VPN, get your kubectl
-  certificate, and verify both actually work.
-- **[Issuing access](./docs/issuing-access.md)** — admin: sign someone's certificate, bind their
-  permissions, and revoke them again.
+1. **The VPN** — everything this tool talks to lives inside the cluster network.
+2. **An admin session for staging** — `remote-environment login`. That is what authorizes the tool to
+   fetch the environment spec, the registry credentials and the BankID material.
 
-Already have both? Straight to the quick start.
+**No kubectl. No cluster credential. No `new-infrastructure` checkout.** All of that moved behind
+`service-dooer-test-env`, which runs in each environment and exposes only the operations this tool needs
+— each one admin-gated and recorded. See
+[the specification](./_specification/service-dooer-test-env.md) for what it replaced and why.
+
+- **[Getting access](./docs/getting-access.md)** — new developer: set up the VPN and log in.
+- **[Logins and user management](./docs/user-management.md)** — signing in as a customer, partner or admin
+  user; creating users; partner membership; using the token from scripts.
+- **[Issuing access](./docs/issuing-access.md)** — admin: VPN tunnels, and cluster certificates for the
+  people who actually operate the cluster. **Not needed to use this tool any more.**
 
 ## Quick start
 
 ```bash
-# 1. One-time: prereq checks, registry login, compose generation, BankID cert → keychain.
-#    Needs the VPN + kubectl access to dooer-staging (see "First time here?" above).
+# 0. Log in to staging as an ADMIN — the local stack is built from staging's live Deployments.
+#    BankID cannot reach an admin account; this has to be email + password.
+npx @dooer/dooer-test-env remote-environment login --env staging --email you+admin@dooer.com
+
+# 1. One-time: prereqs, registry login, environment spec, compose generation, BankID cert → keychain.
+#    Needs the VPN and the admin session above.
 npx @dooer/dooer-test-env setup
 
 # 2. Bring the whole stack up (all staging services + frontends)
@@ -53,7 +65,7 @@ db roles                                          (re)create per-service DB role
 db snapshot <name> | db rollback <name>          local restore points
 customer new "<name>" --owner <userId> --execute empty functional account: company + Owner + subscriptions + partner dooer
 customer copy | customer purge                    copy / delete one org between environments (emails anonymized)
-remote-environment login|become|status|logout|list  sign in to an environment; session → keychain
+remote-environment login|become|token|status|logout   sign in to an environment; session → keychain
 user search | get | create | partners             find/inspect/create users (local env unless --env)
 partner list | users | assign | unassign          partners and who belongs to them, at which level
 shred                                             anonymize the LOCAL db (localhost only)
@@ -167,63 +179,67 @@ user's `--role` at Dooer. Only **`hi`** users can belong to a partner; the CLI a
 
 ### Look at (or fix) users in a real environment
 
-The `user` and `partner` commands talk to an environment's **public GraphQL endpoint** — the same one the
-frontends use — so reaching staging or live needs no VPN, no kubectl and no cluster credentials. It does
-need a session. Sign in once per environment; the token is kept in your keychain:
+The `user` and `partner` commands reach an environment through its **public GraphQL endpoint** — the same
+one the frontends use — so staging and live need no VPN, no kubectl and no cluster credentials. They do
+need a session:
 
 ```bash
-# BankID — exactly what HQ does, so you get your professional (hi) account
+# BankID — what HQ does, so you get your professional (hi) account
 npx @dooer/dooer-test-env@latest remote-environment login --env staging
 
-# email + password (prompted, hidden) — the only way to reach an ADMIN account
+# email + password — the only route to an ADMIN account (BankID cannot reach one)
 npx @dooer/dooer-test-env@latest remote-environment login --env staging --email you+admin@dooer.com
 
-npx @dooer/dooer-test-env@latest remote-environment status --all   # who you are, in every environment
-npx @dooer/dooer-test-env@latest remote-environment logout --env staging
+npx @dooer/dooer-test-env@latest remote-environment status --all
 ```
 
-Then point any command at it with `--env` (`local` is the default; `staging`, `production`, and aliases
-like `dooer-staging` / `live` all resolve):
+Then point any command at it with `--env` (`local` is the default; `staging` / `production` and aliases
+like `dooer-staging` / `live` resolve too):
 
 ```bash
 npx @dooer/dooer-test-env@latest user search someone@dooer.com --env staging
 npx @dooer/dooer-test-env@latest partner list --env production
 ```
 
-**Which account you sign in as decides what you can do**, because one person has several user rows:
-
-| operation | needs | how to get it |
-| --- | --- | --- |
-| reads (`user search`, `user get`) | any session | either login |
-| `partner assign` / `unassign` | a **partner** session | BankID login, or `become` from an admin session |
-| `user create` | an **admin** session | password login as your admin account |
+**Which of your accounts you sign in as decides what you can do** — reads work from any session, partner
+membership needs a partner session, and creating a user needs an admin one. See
+**[Logins and user management](./docs/user-management.md)** for the full picture: the three kinds of user,
+`become`, and the permission matrix.
 
-BankID cannot reach an admin account at all: `loginWithBankIdV2` is pinned to `user_type: 'customer'`
-server-side, and HQ's partner flow resolves your `hi` user. When a session lacks the level, the CLI says
-which one is required and who you are currently signed in as, rather than surfacing a raw `Forbidden`.
+### Use the session token in your own scripts
 
-Signed in as an admin, you can assume a partner user without BankID — the same thing back-office's
-**“Become user in X”** button does (`partner.user.become`, itself admin-gated):
+`remote-environment token` prints the token and nothing else — no colour, no label — so it drops straight
+into a variable or a pipe:
 
 ```bash
-npx @dooer/dooer-test-env@latest remote-environment become someone@dooer.com --env staging
-# …--partner "Dooer Devteam" if they belong to more than one
+TOKEN=$(npx @dooer/dooer-test-env@latest remote-environment token --env staging)
 
-npx @dooer/dooer-test-env@latest remote-environment become --revert --env staging
+curl -s https://api.s-e032.com/graphql \
+  -H "content-type: application/json" -H "authorization: Bearer $TOKEN" \
+  -d '{"query":"{ currentUser { id email userType } }"}'
 ```
 
-Becoming replaces the stored session, so the admin token that authorised it is stashed first and
-`--revert` puts it back — otherwise you would have to log in again just to get where you were.
+The local env needs no login for this — with no stored session it mints one from the shared dev keypair.
 
-The local env needs no login — it is signed with the shared dev keypair this CLI already holds.
+### Copy a real customer into the local env
 
-Writes are dry-run until `--execute`.
+`--target-local` addresses this stack; the source can be any environment (`--source-local` goes the other
+way). Emails are always anonymized. Dry-run by default; add `--execute`.
 
-### Copy a real customer into the local env
+**You need an admin session in BOTH ends.** A copy is two locally-authorized halves — an export authorized
+by admin in the *source* and an import authorized by admin in the *target* — because each environment
+signs its own tokens and neither service will ever validate the other's. That is a stronger check than the
+kubeconfig it replaces, where reaching the cluster was enough. The command is unchanged; the split is
+internal.
 
-`--target-local` addresses this stack (Postgres on 55432 + MinIO); the source can be any k8s namespace
-(`--source-local` goes the other way). Reading production needs no confirmation — only *writing* to it does. Emails are always
-anonymized. Dry-run by default; add `--execute`.
+```bash
+npx @dooer/dooer-test-env@latest remote-environment login --env production --email you+admin@dooer.com
+npx @dooer/dooer-test-env@latest remote-environment login --env staging --email you+admin@dooer.com
+```
+
+Both halves are async, so the command prints progress while it waits. If the source could not read a
+table, the copy says so as a **WARNING** rather than quietly producing a partial org, and both ends record
+the operation in their audit trail (`remote-environment` → the service's `/v1/operations`).
 
 ```bash
 # copy Ghost Inspector out of LIVE into the local env, as a new org owned by a local user
@@ -386,6 +402,10 @@ Inbound *input* validation always runs — this only affects response validation
 
 ## Prerequisites
 
-Docker (Desktop), `kubectl` with access to the `dooer-staging` namespace (VPN), and Node 18+.
+Docker (Desktop), the **VPN**, an **admin session for staging**, and Node 18+.
+
+No kubectl, no cluster certificate, no `new-infrastructure` checkout — `service-dooer-test-env` supplies
+what those used to. Don't have the VPN yet? → **[Getting access](./docs/getting-access.md)**.
 
-Don't have the VPN or a kubectl credential yet? → **[Getting access](./docs/getting-access.md)**.
+`DOOER_TEST_ENV_MANIFESTS=<dir>` still generates from local manifest yaml instead of the live cluster,
+which is useful when you are working on a manifest that is not deployed yet.