Data isolation
One slip and you've shown the wrong board someone's arrears.
You run other people's corporations. Their owners, their money, their disputes — kept apart because the law and the relationship both require it. Most software keeps them apart in application code: a WHERE clause on every query, and a developer's promise that nobody ever forgets one.
uptrack keeps them apart in the database, underneath the application, where forgetting isn't possible.
The lock is in Postgres, not in our code.
Every corporation-scoped table has row-level security enabled and forced. Forced matters: it means even the table's owner is subject to the policy. There's no connection that quietly sees everything.
Each request opens a transaction that sets one session variable — the corporation you're acting in. The policy admits a row only if its corporation matches. A query with noWHERE clause at all returns your corporation's rows and nothing else, because the database will not hand over the rest.
129
tables under forced row-level security — 120 corporation-scoped, 9 party-scoped
1
session variable, set per request, that decides what exists
0
rows returned across a corporation boundary, with or without a filter
A test that fails if anyone forgets.
The weakness of any isolation rule is the table somebody adds next year. So one test asks the database itself: list every table with a corporation column, and tell me which ones aren't locked. If the answer isn't "none", the build fails.
Nobody has to remember. The rule is enforced by something that doesn't forget, and it runs against a real Postgres — not a mock that agrees with us.
- reading inside corp A returns ONLY corp A rows
- corp A cannot see corp B rows even with no explicit filter
- reading inside corp B returns ONLY corp B rows
- writing a corp A row while acting as corp B is rejected by the database
- no corporationId table is missing ENABLE/FORCE row level security
The fourth is the one worth reading twice: the rejection comes from Postgres, not from a check we wrote. The fifth is the one that keeps the other four true a year from now.
What this doesn't cover.
A short list of tables sits outside the lock on purpose — the ones the sign-in path has to read before any corporation context exists: your account, your user record, your membership. They're looked up by unique identifier, never by a corporation-scoped query, and RLS would break the lookup that decides who you are.
We'd rather say that plainly than claim a clean sweep. Anyone who tells you every row in their database is behind a tenant policy hasn't looked at their auth path.
Kept apart, and kept reachable.
Isolation keeps each corporation's data private. The next thing we're building keeps it reachable: the app already loads without a connection, and a local, last-synced copy of your records is going in underneath it — so an internet outage, or a full blackout, doesn't cut your office off from the work in front of you.
It's viewing, not a live mirror, and we'd rather be plain about that. You see your data as of the last sync — today's work orders, the units and files you've had open — not the whole portfolio, and not a change someone made elsewhere while you were dark. Enough to keep the day moving until the connection is back. Editing while offline is a harder problem, and we're not going to pretend it's already solved.
Ask us the hard version.
If you've been burned by software that mixed two properties up, you'll have specific questions. Bring them.