Propflow Propflow Docs
Acceptedmarkdown source

0135 — Roles stay; privilege enforcement is off for launch; provenance is not

Context

The portfolio architecture (design-final §5.2, "Derived grants — deny by default; D8-A") derives every person's read and write authority from role rows, and eleven board rows (p7-*) build the enforcement: an actor view, org admins losing whole-org sight, the deletion of admin bypasses, owner reports pushed only where a row authorises them. Two things happened on 2026-09-14. First, the new company/building pickers showed the founders' own logins one test company, because staff hold no role rows inside any customer company — a deny-by-default rule renders as a nearly empty, normal-looking list (blocks b89373143, b89412009, PR #8437). Second, at standup, Fede's mental model was stated and agreed: "Keep it simple. They can see everything. And then only the people operating the property can actually go change." Gera went further the same evening: "anyone can see anything and edit anything except obviously system admins will be able to see the admin page and then maintenance specialists will have a little bit more fine tone … everyone can edit settings too for now … the roles aren't gonna be impacting … for now it's just one standard." Three customer companies onboard in the next four to seven weeks; the team's stated philosophy is to surface restrictions as customers ask for them rather than front-load them.

Decision

Within a company, every signed-in person can read everything and change everything, including settings and policies. Roles remain, as data, as labels, and as routing — they do not gate reads or writes for launch. Two carve-outs and one thing that does not change:

  1. Admin pages are gated by platform_admin (the system-admin role). Nothing else is.
  2. Maintenance specialists get scoped surfaces — their own tools and views — as a matter of product shape, not as a denial elsewhere. The exact shape is a later, separate decision.
  3. Tenant isolation is unchanged. "Anyone can see anything" is within their own company. The org fence, the roster gate (in observe mode since 2026-09-14), the cross-company wall and the expiring grants for outside parties (ADR-0134 lineage, decision b89408774) all stand exactly as they are. This ADR relaxes role enforcement, never tenant enforcement.

Provenance is not relaxed. Gera, same night: "we still want to store who changed what … we would have reference to their roles. So if in the future we want to know who did what, we could always check." Every write keeps its actor, its time, and the actor's role at the time of the write. Nothing about the audit infrastructure, the settings registry's write path, or the decision receipts changes. A future ruling may re-introduce role-conditional enforcement; the recorded role is what makes that possible without a migration. Nobody changes their own role; only an admin or the operating party can (invite flow, magic link + SSO, per the standup).

What a future reader should check code against

Effect on the board (portfolio-architecture-phases)

The driver re-scopes, citing this ADR: p7-admin-flip and the enforcement half of p7-actor-view, p7-bypasses (keep only the admin-page gate) and p7-reports (keep the push mechanics, drop the authorisation half) are superseded for launch. p7-login, p7-invite, p7-relationships, p7-staff-job, p7-plink, p7-groups, p7-domain-override are unchanged. design-final §5.2 carries a superseding note pointing here.

Consequences

Amendment — 2026-10-01: job titles carry no privilege; building on/off is the one carve-out

Gera, in chat, 2026-10-01: "remove it… everything regarding their modules — send mass texts, change maintenance or leasing — anyone can do for now. The only thing nobody can do is turning a building on or off; only system admins. System-admin settings are only available and visible to system admins." The same day he narrowed the building carve-out so sign-up keeps working (REVISION 2 of 2026-09-30 still holds for the wizard step): customers may switch buildings on or off during onboarding only.

What this changes, on top of the decision above:

  1. Customer job titles gate nothing. The remaining matrix gates (requireEntityEdit, hasEntityCapability, requireRole over customer roles) are replaced, area by area, by one rule, requireWorkspaceMember (src/lib/domain/identity/require-workspace-member.ts). Any member of the company's workspace may act, whatever their role, and a resident login is still refused. Building access (assignment plus company scope) still decides which buildings; that is tenancy, and §3 above stands.
  2. Turning a building on or off is the one carve-out. After onboarding, only PropFlow system admins may flip building.in_propflow. During onboarding, a customer may, while the company still shows them the table (buildings.customer_control). The onboarding window is the existing one: the company is not live, isCompanyOnboarding (src/lib/domain/onboarding/onboarding-access.ts). One predicate, customerMaySwitchBuildings (src/lib/domain/modules/building-switches.ts), answers both the write door and the read route's canEdit, so customers see the switch read-only after onboarding.
  3. Adding a building (POST /api/properties) and archiving one (ignored-properties with alsoDelete) are system-admin only under the same ruling. They ship separately, after this one.

A future reader should treat a customer write refused because of a job title as a violation of this ADR. A customer switching a building on or off after their company is live is also a violation.