Access rules in the export

What the policies reproduce

The export bundle includes policies.sql, which sets up row-level security on the exported tables. A user sees a row when they own it, when it is public, when they were explicitly granted it, or when it hangs off something they can already see. That last case reaches one level, through a reference that carries read access. Explicit grants travel in their own table, which the policies consult and users cannot read directly.

Inside Fóir the rules are enforced in the database, compiled by Demesne against a single records table. The export has a table per model, so the same rules are written again for that shape.

Applying them

You run the file with psql after the data has loaded. Applying the bundle through the export command does not run it. From then on the contract is one session setting, request.jwt.claims, carrying the user's id. With no claims set, the caller is anonymous and sees exactly the public rows. Test as the authenticated role: the role that restored the tables owns them, and a table's owner bypasses row-level security.

What does not transfer

Field-level permissions, API scopes and write rules stay behind. A user who can see a row in the restored database sees every column of it, so hiding a field becomes the job of your application, a column grant or a view. The policies give anonymous and signed-in callers read access only, and your team's console access is not exported.

What is tested

Our test suite exports a seeded project, restores it into a second database, applies the policies and requires the same row ids for the same user on both sides. That tests the translation, and nothing checks the policies on your own restored database. We make no claim that the restored rules match for a project that uses organisations.