@dooer/dooer-test-env 1.13.0 → 1.15.0

package/readme.md

@@ -53,6 +53,9 @@ 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
+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)
 bankid pull | status | clear                      BankID cert (staging → keychain), used by service-accounts
 validation on | off | status                      output-schema validation (default OFF, like staging/live)
@@ -109,13 +112,113 @@ reads (`fiscalYear`, `hasVatRegistration`, `hasCompanyTax`, `hasEmployeeRegistra
 `vatPeriod`/`vatDue`). `--no-fiscal-year` leaves all of that blank.
 
 The owner must be a **`customer`** user — a `hi`/admin owner cannot accept Terms of Service and the command
-warns you. Find one with:
+warns you. Find one:
 
-```sql
-SELECT users_pk, email FROM service_accounts.users
-WHERE fk_user_roles_at_dooer_pk = 'customer' AND inactivated_at IS NULL LIMIT 5;
+```bash
+npx @dooer/dooer-test-env@latest user search --role customer
 ```
 
+### Create a user you can actually log in as
+
+```bash
+# an accounting professional (role `hi`) in the local env, password generated and printed once
+npx @dooer/dooer-test-env@latest user create --email anna@dooer.com --execute
+
+# …a customer instead, with your own password and a personnummer
+npx @dooer/dooer-test-env@latest user create --email kim@example.com \
+  --role customer --password 'hunter2hunter2' --personnummer 19900101-1239 --execute
+
+# …or an `hi` user placed straight into a partner
+npx @dooer/dooer-test-env@latest user create --email anna@dooer.com \
+  --partner "Dooer Devteam" --level admin --execute
+```
+
+This goes through `users.create` — the same mutation back-office's `/users/new` calls — so the service
+hashes the password itself and applies its own input validation. The password works on the ordinary
+email+password login, no BankID needed, and is shown **once**; there is no way to read it back. `--role`
+defaults to `hi` (other choices: `customer`, `admin`) and names default to something derived from the
+address.
+
+The personnummer must be a **real** one: the API checks the Luhn digit, so an invented number is rejected
+(the CLI checks it first and tells you which rule failed). Creating a user needs an **admin** session in a
+remote environment — see below.
+
+Look users up by email **or** id, and see where they belong:
+
+```bash
+npx @dooer/dooer-test-env@latest user search anna          # email, name, personnummer or id
+npx @dooer/dooer-test-env@latest user get anna@dooer.com   # details + partner memberships
+```
+
+### Partners and who belongs to them
+
+```bash
+npx @dooer/dooer-test-env@latest partner list                        # every partner in the environment
+npx @dooer/dooer-test-env@latest partner users "Dooer Devteam"       # its users and their level
+
+# add / promote / remove (a partner is addressable by id, name or domain)
+npx @dooer/dooer-test-env@latest partner assign anna@dooer.com "Dooer Devteam" --level admin --execute
+npx @dooer/dooer-test-env@latest partner unassign anna@dooer.com "Dooer Devteam" --execute
+```
+
+`--level` is the membership level inside the partner (`member` or `admin`) — not the same thing as the
+user's `--role` at Dooer. Only **`hi`** users can belong to a partner; the CLI applies the same
+`invalid-user-type` check the service-accounts API does rather than writing a row HQ would choke on.
+
+### 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:
+
+```bash
+# BankID — exactly 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
+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
+```
+
+Then point any command at it with `--env` (`local` is the default; `staging`, `production`, and aliases
+like `dooer-staging` / `live` all resolve):
+
+```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 |
+
+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`.
+
+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):
+
+```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
+
+npx @dooer/dooer-test-env@latest remote-environment become --revert --env staging
+```
+
+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 — it is signed with the shared dev keypair this CLI already holds.
+
+Writes are dry-run until `--execute`.
+
 ### Copy a real customer into the local env
 
 `--target-local` addresses this stack (Postgres on 55432 + MinIO); the source can be any k8s namespace