You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(cli): add project rename, remove, and transfer (#107)
Completes the `project` group's remote lifecycle: rename, remove, and
transfer. Spec-first (`command-spec.md` + `resource-model.md` updated in
the same change).
```bash
$ prisma-cli project rename "Acme Dashboard v2"
✔ Renamed. Directory bindings pin the project id, so they stay valid.
$ prisma-cli project remove proj_999 --confirm proj_999
✔ The project, its databases, and its apps were removed.
This directory's local project binding was cleared.
$ prisma-cli project transfer proj_123 --to-workspace "Prisma Labs" --confirm proj_123
✔ The project now belongs to the recipient workspace.
This directory's local project binding now points at the recipient workspace.
```
Design notes
- The transfer API authorizes with a recipient *access token*, not a
workspace id. `--to-workspace` resolves a locally stored OAuth session
(same targets as `auth workspace use`) through a new workspace-pinned
`FileTokenStorage` view that refreshes via the SDK and can never move
the active-workspace selection; `--recipient-token` is the
cross-account/headless path. Under `PRISMA_SERVICE_TOKEN`,
`--to-workspace` fails with `TRANSFER_RECIPIENT_UNAVAILABLE`.
- Remove and transfer take an explicit positional target (never the
bound project) plus exact-id `--confirm`.
- Local pin hygiene: remove clears a matching `.prisma/local.json`;
transfer rewrites it to the recipient workspace when known, else clears
it; both best-effort with warnings.
- Structured codes: `PROJECT_REMOVE_BLOCKED` (active deployments),
`PROJECT_TRANSFER_REJECTED`, `PROJECT_RENAME_FAILED`,
`TRANSFER_RECIPIENT_REQUIRED`/`_UNAVAILABLE`, `CONFIRMATION_REQUIRED`
with meta.
Testing: 14 new integration tests, full suite green, and all three
commands verified against the live Management API with scratch projects,
including a real cross-workspace transfer (project visible in the
recipient workspace, pin rewritten, cleaned up afterwards).
Note: merge after #106 or rebase; both touch `mock-api.ts`/fixtures.
- resolves `<project>` by exact Project id or exact Project name inside the active workspace; the positional target is required and never defaults to the directory's bound Project
759
+
- exactly one recipient source is required:
760
+
-`--to-workspace <id-or-name>` resolves a locally authenticated OAuth workspace, the same targets `auth workspace use` accepts, and authorizes the transfer with that workspace's stored session; this is the same-user path
761
+
-`--recipient-token <token>` passes an access token for the receiving workspace directly; this is the cross-account and headless path
762
+
-`--to-workspace` and `--recipient-token` are mutually exclusive; passing neither fails with `TRANSFER_RECIPIENT_REQUIRED`
763
+
-`--to-workspace` fails with `WORKSPACE_NOT_AUTHENTICATED` or `WORKSPACE_AMBIGUOUS` when no unique local OAuth session matches, and with `TRANSFER_RECIPIENT_UNAVAILABLE` when `PRISMA_SERVICE_TOKEN` is set, because service-token mode does not read local OAuth sessions
764
+
- requires `--confirm <project-id>` where the value exactly matches the resolved Project id; `--yes` does not satisfy this confirmation
765
+
- after the transfer the Project belongs to the recipient workspace and the source workspace loses access; Project, Branch, App, and database ids are unchanged
766
+
- when this directory's `.prisma/local.json` pin points at the transferred Project: with `--to-workspace` the pin's workspace id is rewritten to the recipient workspace, otherwise the pin is cleared; the result reports which happened
767
+
- fails with `PROJECT_TRANSFER_REJECTED` when the platform rejects the transfer, for example an invalid or expired recipient token
768
+
- fails with `PROJECT_NOT_FOUND` or `PROJECT_AMBIGUOUS` when the target cannot be selected safely
769
+
770
+
Examples:
771
+
772
+
```bash
773
+
prisma-cli project transfer proj_123 --to-workspace "Prisma Labs" --confirm proj_123
774
+
prisma-cli project transfer proj_123 --recipient-token <token> --confirm proj_123
775
+
prisma-cli project transfer proj_123 --to-workspace wksp_456 --confirm proj_123 --json
Copy file name to clipboardExpand all lines: docs/product/resource-model.md
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -42,6 +42,10 @@ Rules:
42
42
- Project setup is explicit: users choose an existing Project or explicitly create a new one before remote work starts
43
43
-`app deploy` may orchestrate Project setup, but it must not silently choose or create Project scope
44
44
- everything under a project happens in a branch
45
+
-`project rename` mutates only the remote Project name; pins bind by id and stay valid
46
+
-`project remove` and `project transfer` take an explicit positional Project target and exact id confirmation with `--confirm <project-id>`; they never default to the directory's bound Project and `--yes` is not sufficient
47
+
- removal is permanent and takes the Project's databases with it; transfer moves ownership to another workspace without changing resource ids
48
+
- when a destructive Project command invalidates this directory's local pin, the CLI cleans the pin up (clear on remove; rewrite or clear on transfer) and reports it
0 commit comments