Table permissions
There are three possible permission levels per table: no access, read, or write. They can be set both directly on a user and on a group (the same editor in both places).
Resolving the actually effective permission for a viewer, in this order:
- An individual override set directly on the user – if present, it always wins.
- Otherwise, the highest permission across all of the user’s groups.
- Otherwise, the default: read for every logged-in viewer.
An admin bypasses this whole check – they always have full write access, no matter what’s configured here.
Public read access
In addition to the user/group permission above, any table can individually be set to publicly readable – via the dropdown in the “Access” column in a data source’s table overview (Settings → Data Sources → select a table).
This affects only that table’s read-only data endpoints: fetching records (single or as a list), CSV export, table schema, saved views, values for selection lists, and file attachments. Once a table is marked this way, exactly these endpoints become reachable without logging in at all – handy, for example, to use IllusionDB as the backend for a public blog whose content should be served directly, without a login.
Explicitly not affected:
- Write access to this table (create/edit/delete a record, upload attachments) – stays bound to the user/group permission above, as usual.
- Schema changes (columns, creating views, toggling public access itself) – stay admin-only.
- Every other, non-table-related endpoint (user management, groups, audit log, data source management, etc.).
Public read access is purely additive: it doesn’t change the user/group permission resolution described above for logged-in users, it only additionally allows unauthenticated access to this specific table.