Create organizations, manage teams and transfers, fix collaborator permissions #282

Merged
stephen merged 1 commit from feat/spec-parity-org into feat/spec-parity-issues 2026-10-08 19:42:48 +00:00
Owner

Four forge-organization-management requirements and one repositories
requirement of the fjord-client-spec.

fj org create validates the name and fields locally, then prints the
organization the server returned. A permission denial and a name
conflict get different headlines.

fj org team create|members|add-member|remove-member|repos|add-repo| remove-repo. Every mutation is followed by a read, and the command
errors if that read contradicts the change. Team creation and member
changes are refused before sending when the account is neither an org
owner nor a site admin; add-repo and remove-repo have no local preflight
and rely on the server's 403.

fj repo collaborator list reported every permission as none: the list
endpoint sends permissions: null and the field defaulted to all-false.
It is now optional, and the list resolves each row through the
per-collaborator permission endpoint. A 403 on a row leaves it "unknown",
never "none". add and remove now confirm against the server.

fj repo transfer request inspects before it asks: it resolves the new
owner, refuses an unknown owner, the current owner and an already
pending transfer, and prints who has to accept. fj repo transfer list|view|accept|reject review incoming transfers. Forgejo has no
incoming-transfer endpoint, so list scans the caller's repository
listings and can miss a transfer addressed to one of their orgs;
view -R always works. The help text says so.

fj repo topics add|remove use the single-topic routes and print the
list the server confirms. --set now reads back too instead of echoing
its own input, and validates topic names locally.

Covered by unit and wiremock tests only; nothing here was run against a live forge. repo transfer list is knowingly partial, for the reason above.

Part 5 of 8 in the spec-parity stack. Based on feat/spec-parity-issues, so the diff here is this slice alone; it needs a rebase onto main once the PR below it is squash-merged.

Fixes #276

Verified on macOS at this commit: cargo fmt --all clean, cargo clippy --all-targets --all-features -- -D warnings clean, cargo test --all green.

Four forge-organization-management requirements and one repositories requirement of the fjord-client-spec. `fj org create` validates the name and fields locally, then prints the organization the server returned. A permission denial and a name conflict get different headlines. `fj org team create|members|add-member|remove-member|repos|add-repo| remove-repo`. Every mutation is followed by a read, and the command errors if that read contradicts the change. Team creation and member changes are refused before sending when the account is neither an org owner nor a site admin; add-repo and remove-repo have no local preflight and rely on the server's 403. `fj repo collaborator list` reported every permission as none: the list endpoint sends `permissions: null` and the field defaulted to all-false. It is now optional, and the list resolves each row through the per-collaborator permission endpoint. A 403 on a row leaves it "unknown", never "none". `add` and `remove` now confirm against the server. `fj repo transfer request` inspects before it asks: it resolves the new owner, refuses an unknown owner, the current owner and an already pending transfer, and prints who has to accept. `fj repo transfer list|view|accept|reject` review incoming transfers. Forgejo has no incoming-transfer endpoint, so `list` scans the caller's repository listings and can miss a transfer addressed to one of their orgs; `view -R` always works. The help text says so. `fj repo topics add|remove` use the single-topic routes and print the list the server confirms. `--set` now reads back too instead of echoing its own input, and validates topic names locally. Covered by unit and wiremock tests only; nothing here was run against a live forge. `repo transfer list` is knowingly partial, for the reason above. Part 5 of 8 in the spec-parity stack. Based on `feat/spec-parity-issues`, so the diff here is this slice alone; it needs a rebase onto main once the PR below it is squash-merged. Fixes #276 Verified on macOS at this commit: `cargo fmt --all` clean, `cargo clippy --all-targets --all-features -- -D warnings` clean, `cargo test --all` green.
Four forge-organization-management requirements and one repositories
requirement of the fjord-client-spec.

`fj org create` validates the name and fields locally, then prints the
organization the server returned. A permission denial and a name
conflict get different headlines.

`fj org team create|members|add-member|remove-member|repos|add-repo|
remove-repo`. Every mutation is followed by a read, and the command
errors if that read contradicts the change. Team creation and member
changes are refused before sending when the account is neither an org
owner nor a site admin; add-repo and remove-repo have no local preflight
and rely on the server's 403.

`fj repo collaborator list` reported every permission as none: the list
endpoint sends `permissions: null` and the field defaulted to all-false.
It is now optional, and the list resolves each row through the
per-collaborator permission endpoint. A 403 on a row leaves it "unknown",
never "none". `add` and `remove` now confirm against the server.

`fj repo transfer request` inspects before it asks: it resolves the new
owner, refuses an unknown owner, the current owner and an already
pending transfer, and prints who has to accept. `fj repo transfer
list|view|accept|reject` review incoming transfers. Forgejo has no
incoming-transfer endpoint, so `list` scans the caller's repository
listings and can miss a transfer addressed to one of their orgs;
`view -R` always works. The help text says so.

`fj repo topics add|remove` use the single-topic routes and print the
list the server confirms. `--set` now reads back too instead of echoing
its own input, and validates topic names locally.

Fixes #276
stephen merged commit f71ef45cc3 into feat/spec-parity-issues 2026-10-08 19:42:48 +00:00
stephen deleted branch feat/spec-parity-org 2026-10-08 19:42:48 +00:00
Sign in to join this conversation.
No description provided.