Diego ImbertandClaude Opus 5 ec19b0fe21 fix(datatables): a generated login belongs to one data table in one workspace ...

Three ways it could stop being true, all of them ending with a login shared
between two data tables or outliving every record of itself:

A rename carried the roles verbatim, and their names are made from the data
table's name — so a data table created under the name that was left behind
generated those same names, adopted those logins and reset their passwords.
Renaming a permissioned data table is refused, the way pointing one at another
database already is.

Deleting a workspace removed the settings that name its logins without dropping
them. What to drop is resolved while that row is still there and run after the
commit, like a data table's own deletion — a workspace id is reusable, so what
survived was adoptable by the next workspace of that name.

Generating the initial migration takes a `pg_dump` with the data table's own
connection and returns every object in it, on nothing but `ApiAuthed` — a member
who may run as no role could read the whole schema through it. It answers to the
gate the rest of the migration management does.

The raw app's data drawer asks for its tree when it opens, like the manager's.

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

2026-09-04 18:50:00 +02:00

..

src

fix(datatables): a generated login belongs to one data table in one workspace

2026-09-04 18:50:00 +02:00

Cargo.toml

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

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