Skip to content

Allow creating the first organization via qovery api organization - #702

Merged
jul-dan merged 4 commits into
mainfrom
fix/allow-org-creation-with-zero-orgs
Aug 31, 2026
Merged

Allow creating the first organization via qovery api organization#702
jul-dan merged 4 commits into
mainfrom
fix/allow-org-creation-with-zero-orgs

Conversation

@jul-dan

@jul-dan jul-dan commented Aug 31, 2026

Copy link
Copy Markdown
Contributor

Summary

  • GetAccessToken() validates the token by calling ListOrganization() and hard-fails with "you don't have any organization. Please create an account on https://start.qovery.com ." whenever the list is empty — before the actual request is even sent.
  • This blocks every qovery api ... call for a brand-new account, including the org-creation call itself: qovery api organization --field name=... --field plan=..., which qovery api --help documents as a first-class example.
  • Net effect: a new user cannot bootstrap their first organization through the CLI at all, and has to detour through the web console just to create it — even though the CLI's own docs say otherwise.

Fix

  • Extracted the existing logic into getAccessToken(skipOrgaCheck bool), keeping GetAccessToken() behavior unchanged for every existing caller.
  • Added GetAccessTokenAllowNoOrg(), used only by runAPI (cmd/api.go) when the request is exactly POST /organization — the one legitimate case where having zero organizations is expected.
  • Every other qovery api call (and every other command using GetAccessToken) keeps the existing guard against operating with no organization to scope to.

Test plan

  • go build ./cmd/... ./utils/... and go vet ./cmd/... ./utils/... — clean (pre-existing go vet ./... failures in unrelated packages are due to missing generated mocks, unaffected by this change)
  • gofmt -l cmd/api.go utils/context.go — no diff
  • Manually verified end-to-end against production API with a brand-new account that had zero organizations:
    • qovery api organization --field name="..." --field plan=BUSINESS_2025 now succeeds (200, returns the created org)
    • Confirmed the org is real via the Console
    • After a fresh qovery auth --headless (to pick up the new org's role claim in the JWT), qovery api organization (unpatched binary) lists it normally, and every other command continues to correctly reject zero-organization accounts

🤖 Generated with Claude Code


Summary by cubic

Allows qovery api organization --method POST to create the first organization on a new account instead of failing with "you don't have any organization" before the request is sent. GetAccessToken() now takes a skipOrgaCheck bool; every call site passes false except runAPI for the exact POST /organization path and auth status, which pass true so zero-organization accounts can create their first org and still be recognized as authenticated, while all other commands keep the guard.

Written for commit 64753e3. Summary will update on new commits.

Review in cubic

GetAccessToken() calls ListOrganization() to validate the token, then
rejects any qovery api call outright when the org list is empty — even
when the call being made is the org-creation call itself. This makes
the documented `qovery api organization --field name=... --field
plan=...` example (shown in `qovery api --help`) impossible to run for
a brand-new account with zero organizations, forcing a detour through
the web console just to bootstrap the very first org.

Add GetAccessTokenAllowNoOrg(), used only by runAPI when the request
is exactly `POST /organization`, to skip that guard for this one
legitimate bootstrap case. Every other `qovery api` call keeps the
existing protection against operating with no organization to scope
to.

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All reported issues were addressed across 2 files

Reply with feedback, questions, or to request a fix.

Re-trigger cubic

Comment thread cmd/api.go Outdated
Comment thread utils/context.go Outdated
Comment thread utils/context.go
jul-dan and others added 2 commits August 31, 2026 14:01
Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
- Per review feedback, drop the GetAccessToken()/GetAccessTokenAllowNoOrg()
  wrapper pair and export getAccessToken directly as
  GetAccessToken(skipOrgaCheck bool). Every existing call site is updated
  to pass false; only runAPI's org-creation path passes true.
- Add utils/context_test.go: unit tests for checkOrgaValid, plus an
  httptest-backed end-to-end test proving GetAccessToken(false) still
  rejects a zero-organization account for every other command while
  GetAccessToken(true) allows it through for org creation only.

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All reported issues were addressed across 173 files (changes from recent commits).

Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic

Comment thread cmd/auth_status.go Outdated
Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
@jul-dan
jul-dan merged commit 9a29ea0 into main Aug 31, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants