Diego ImbertandClaude Opus 5 497f24bca7 feat(datatables): a fork shares its parent's data table, restrictions and all ...

A permissioned data table used to be dropped from a fork's config outright:
copying it would either hand every fork member the connection that owns the
parent's database, or freeze the parent's tenant lists at the moment of the
fork. So a fork could not use one at all.

It now gets a pointer instead — `shared_datatables: {"<name>": {"from":
"<workspace>"}}`, deliberately outside `datatables`, so nothing that plans
role drops or reads which logins a workspace claims can see it. Resolution
follows the pointer and asks every question of the workspace that owns it:
its live config, its live roles, and the caller as *that* workspace knows
them. Checking the fork's own identity would have made forking the way to
reach a data table as admin, since `can_use_datatable_role` starts at
`is_admin` and a fork's owner is an admin of their own fork.

A member of the fork who is not a member of the owner is refused, and does
not see the data table at all. A job permissioned as a folder or a group is
refused too: those exist per workspace, so the fork's admin creates both
sides of the name.

Administering it — permissions, ACLs, migrations, role drops — is refused
from the fork and belongs to the workspace that owns it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S5arH3G2Sa1Qqm32veJQ1n

2026-09-04 22:42:29 +02:00

..

src

feat(datatables): a fork shares its parent's data table, restrictions and all

2026-09-04 22:42:29 +02:00

Cargo.toml

feat: add SQL migrations for data tables (#9693)

2026-07-07 08:25:16 +00:00