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.
Fields from other tables
Lookup, rollup, links and child-records fields show data from another table. If the caller may not read that other table, the field is hidden for them – in the interface and in the API (column list, records, export). Filtering, sorting, grouping and summaries on such a field are rejected as if the field didn’t exist. The same applies to formulas that use a hidden field, and to chains (e.g. a lookup onto a lookup that reaches into a restricted table).
A foreign key into an unreadable table stays visible – it belongs to the table itself – but shows only the raw id instead of the target table’s display value; a filter then compares against the id as well.
“May read” means: admin, read permission via user or group – or, without signing in, a publicly readable target table. So for a public table with a lookup into a non-public table, visitors who aren’t signed in don’t see the lookup field.