PR 15990 · the shell stops seeding your own buildings under a company you don't hold

Captured on stage as a real customer company admin (org_admin, not staff): the same pages with a link naming a company this login does not hold, and without one. The capture found that the top-bar picker looks unchanged and that one page now says something false.

3 Oct 2026 · branch fix/workspace-shell-refuses-ungranted-org · captured against propflow-stage · at 61082d26709+local

Data note. Every name and balance below comes from propflow-stage, which is anonymized by construction (ADR-0097/0110 — phones in the impossible +1000 NPA, emails @example.test). The identical capture against prod would carry real tenants' names and balances and is not safe to attach anywhere, which is why the generator refuses to run against one.

1 · Tenants, linked to a company this login does not hold

The page body refuses the address. That refusal was already on main and is not this PR. The top-bar picker still reads "All Properties". For a customer login, the picker's rows come from the login's grants (the selection provider, which this PR must not change); the seeded building list only supplies names. So the closed picker looks the same before and after this PR. The PR body's claim that "the top bar lists no buildings" is wrong and is being corrected.

Asserted in the captured DOM — You don't have access

Tenants, linked to a company this login does not hold
Sections 2–4

2 · Tenants, no company in the link (the normal case)

The normal case is unchanged.

Asserted in the captured DOM — Tenants

Tenants, no company in the link (the normal case)

3 · Building settings, linked to a company this login does not hold

A defect this PR introduces. This page has no refusal of its own and reads the seeded building list directly. With the list empty, it tells the viewer "there is no building on this account yet". That is false: the login does have buildings. On main the same address showed the normal sentence below it, under the default company. Neither is right, but the new wording states something untrue.

Asserted in the captured DOM — Pick a building · there is no building on this account yet

Building settings, linked to a company this login does not hold

4 · Building settings, no company in the link (the normal case)

The normal case is unchanged: "Choose one in the bar above to edit its settings."

Asserted in the captured DOM — Pick a building · Choose one in the bar above

Building settings, no company in the link (the normal case)
PropFlow Docs