Skip to content

Check pool ownership and take new owners from the caller's org - #417

Merged
Priyanshu-u07 merged 1 commit into
mainfrom
fix/pool-route-ownership
Oct 18, 2026
Merged

Priyanshu-u07 merged 1 commit into
mainfrom
fix/pool-route-ownership

Conversation

@Priyanshu-u07

Copy link
Copy Markdown
Collaborator

Pool routes now act only on pools that belong to the caller's organisation, and new pools and deployments are recorded under that organisation.

  • pool/{id}, list/pool/{id}/inventory, listDeployments/{id}, updatepool, stoppool, deletepool and DELETE pool/{id} answer 404 for a pool outside the caller's org, before any work. System pools belong to no org.
  • listPools lists the caller's org; the org in the path is ignored, and a caller with no org gets an empty list.
  • createpool always records the caller's org as the owner, whatever the body says, and refuses a caller with no org (403).
  • deploy records the caller's org on the deployment, whatever the body says, refuses a caller with no org (403), and only targets the caller's own pools.
  • The audit lookup for pools recorded no org: it compared owner_type with "org", a value never stored. It now uses the same owner types as the ownership check.

Until the CLI follow-up lands, CLI pool commands need --org-id.

Tests cover each route for another org, an empty org, "None", no org, the owning org and a system pool; the cross-org cases fail on main. Verified on a local stack, including the CLI's no-org path and the dashboard's pool and deployment pages.

Signed-off-by: Priyanshu-u07 <connect.priyanshu8271@gmail.com>
@Priyanshu-u07
Priyanshu-u07 merged commit 27fea46 into main Oct 18, 2026
1 check 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.

1 participant