Skip to content

feat: PPT-526 seed the management partner and own the placeholder estate - #105

Draft
camreeves wants to merge 4 commits into
masterfrom
PPT-526-tenancy
Draft

camreeves wants to merge 4 commits into
masterfrom
PPT-526-tenancy

Conversation

@camreeves

@camreeves camreeves commented Oct 7, 2026 •

Copy link
Copy Markdown
Contributor

Clean-install half of multi-tenancy (under PPT-526). Pairs with PlaceOS/models#332 and PlaceOS/rest-api#451. Draft until the set has been through a clean install on the test cluster.

What this does

  • start creates the management partner ("PlaceOS", management = true) and its staff organisation (partner_staff = true), and attaches the first domain to that organisation. With enforcement on, the seeded admin therefore has cluster reach from the first boot rather than reaching nothing.
  • Placeholder zones, system, module and trigger are created owned by that organisation, so a fresh non-production install has no unowned rows. The create:placeholders task does the same when a staff organisation exists.
  • Builds against the models branch through shard.override.yml, and the image clones that branch for its migrations, so a clean install from this image applies the tenancy schema.

On a cluster that predates tenancy, the backfill migration (which runs before start) has already given the first domain an organisation of its own. While that organisation is still exactly as the backfill created it (no partner, no other domain, the backfill's description), start moves everything it owns, and any grants scoped to it, into the staff organisation and removes it, in one transaction. An organisation an operator has changed is left alone.

Both seeding steps are idempotent in the same way as the existing ones: existing rows are reused, never changed, except that an unowned first domain is attached.

Verification

  • Rebased onto master (2026-11-05), tracking models PPT-526-partner-client at b502009 (pg-orm 2.5.3). The spec migrator now also clones that branch, so specs run against the tenancy schema.

  • spec/entities_spec.cr: fresh install, idempotent re-run, backfilled estate moved, operator-changed and multi-domain organisations left alone. 13 examples, 0 failures.

  • Before merging, once models #332 is on master: revert the branch pins in Dockerfile, spec/migration/Dockerfile and shard.override.yml.

  • crystal build --no-codegen clean for start and sam.

  • The tenancy fixture in rest-api#451 (spec/spec_helpers/tenancy.cr) builds the same shape this seeds, and its specs show a staff-organisation admin resolving to cluster reach.

Plan: https://gist.github.com/camreeves/3fabfff92bcdef77a1dcb4b8d8ebfe7b

@github-actions github-actions Bot added type: enhancement new feature or request and removed type: enhancement new feature or request labels Oct 7, 2026
camreeves and others added 3 commits November 6, 2026 14:59
start creates the management partner and its staff organisation and
attaches the first domain to it, so the seeded admin has cluster reach
once tenancy enforcement is on. Placeholder rows are created owned by that
organisation. Builds and clones migrations from the models tenancy branch
until models #332 merges.
Picks up pg-orm 2.5.3, which models now requires.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The spec migrator cloned models master, so specs ran without the tenancy
columns the seeding code writes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@github-actions github-actions Bot added type: enhancement new feature or request and removed type: enhancement new feature or request labels Nov 6, 2026
On a cluster that predates tenancy the backfill migration runs before
`start` and gives the first domain an organisation of its own, so the
seeding never attached it to the staff organisation and its admins would
have no cluster reach once enforcement is on.

While that organisation is still as the backfill created it (no partner, no
other domain, the backfill's description), move everything it owns and the
grants scoped to it into the staff organisation and remove it, in one
transaction. Organisations an operator has changed are left alone.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@github-actions github-actions Bot added type: enhancement new feature or request and removed type: enhancement new feature or request labels Nov 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

type: enhancement new feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants