Tenants

OneStarter is a multi-tenant application by design. This means that each user can belong to multiple tenants. However, each tenant is securely siloed from one another.

Tenants all have a unique slug associated with them which can be used to navigate to their protected workspaces within your application. Once there (e.g. /org/orgSlug/* routes), users will be restricted by their roles and permissions within the user-tenant context.

Each table with tenant row-level security should have a tenant_id column. When you apply row level rules, you can use the either of the following checks:

-- as a policy rule with the helper function has_permission_in_tenant
create policy "my new insert rule" on api.my_table
    for insert
    to authenticated
    with check (api.has_permission_in_tenant(tenant_id, 'insert/my_table') = true);

create policy "my new select rule" on api.my_table
    for select
    to authenticated
    using (api.has_permission_in_tenant(tenant_id, 'select/my_table') = true);

-- with the stored proecdure add_rls_tenant_permission_policy
-- these are equivalent with the above
call private.add_rls_tenant_permission_policy('api', 'my_table', 'select');
call private.add_rls_tenant_permission_policy('api', 'my_table', 'insert');

You can find more security-related details about multi-tenancy in this document

By default, anybody can create a tenant in OneStarter. This is done from the Personal Console (/me) route, or from the tenant dropdown in a modal. You may wish to restrict this based on your use case.