mainsequence-metatable 0.1.47.dev76__tar.gz → 0.1.48.dev77__tar.gz

{mainsequence_metatable-0.1.47.dev76 → mainsequence_metatable-0.1.48.dev77}/.agents/skills/client/metatables-migrations/SKILL.md

@@ -46,29 +46,28 @@ migrations. Read `docs/client/deploy-application-migrations.md`.
 1. **Develop locally.** Author the revision and apply it to verified local SQLite
    with the [local development skill](../metatables-local-development/SKILL.md).
 2. **Commit the revision with the code that needs it.**
-3. **Give the Job access.** Any person admitted to the Environment sets it up; no
-   Organization admin is needed. Follow "Give the Job access" in
-   `docs/client/deploy-application-migrations.md`, in this order, in each
-   Environment:
-   1. Before the first push, create each namespace the provider creates tables in:
-      **Create namespace** in that Environment's Admin, or `Namespace.create(name)`
-      from the person's own session connected to it. The creator becomes `owner`.
-   2. Push the workflow file. It creates the Job's and the other resources' workload
-      Users before any step runs, so the first migration may stop with
-      `namespace_access_required`.
-   3. As owner, grant the migration Job's workload User `editor`, and `data_writer` to
-      resources that only read and write rows, in the namespace's Access panel (find
-      a workload by its Job or release name) or with `grant_role` and its
-      `workload_user_uid`. A Team the owner belongs to, holding the roles with the
-      workloads as members, is optional; it saves granting again when a Job is
-      recreated.
-   4. Re-run the migration Job.
-
-   These are the person's actions, made in MetaTables, not in the repository. Tell
-   the user the steps; with their explicit go-ahead you may run `Namespace.create`
-   and `grant_role` from their session against the target Environment. Never put them
-   in the migration Job: workloads are refused. A namespace created before ADR 0024
-   has no owner until an Organization admin grants one. Recommend one namespace per
+3. **Give the Job access.** Nothing is created by hand and no Organization admin is
+   needed. Follow "Give the Job access" in `docs/client/deploy-application-migrations.md`,
+   in each Environment:
+   1. Push the workflow file. It creates the Job's and the other resources' workload
+      Users before any step runs.
+   2. The first migration registers the provider's tables. A namespace they name that
+      does not exist yet is created by that registration, and the Job gets `editor` on
+      it. Do not tell the user to create the namespace before the push.
+   3. A person who manages the Job in the platform then manages the namespace's
+      access: grant `data_writer` to resources that only read and write rows, and
+      `owner` to themselves or to a Team they belong to, in the namespace's Access
+      panel (find a workload by its Job or release name) or with `grant_role` and its
+      `workload_user_uid`. A Team holding the roles with the workloads as members is
+      optional; it saves granting again when a Job or release is recreated.
+
+   Step 3 is the person's action, made in MetaTables, not in the repository. Tell the
+   user the step; with their explicit go-ahead you may run `grant_role` from their
+   session against the target Environment. Never put grants in the migration Job:
+   workloads are refused. If the namespace name is already taken, the first run stops
+   with `namespace_access_required`; an owner grants the Job `editor`, or the
+   application uses another namespace. A namespace created before ADR 0024 has no
+   owner until an Organization admin grants one. Recommend one namespace per
    application; it is not required (see "Namespaces and applications" in
    `docs/security/ownership-and-sharing.md`).
 4. **Deploy.** The application's `.mainsequence/workflows/` file declares a
@@ -268,10 +267,10 @@ Read `docs/operations/recovery-and-observability.md`.
   another install overwrote it. Move the provider under an application-owned
   module (see [Provider placement](#provider-placement)), preserving its provider
   identity and applied revision history. Do not edit files in `site-packages`.
-- If reservation fails with `namespace_not_found` (403), create the namespace and
-  grant the Job `editor`, as in step 3. `namespace_access_required` is expected on a
-  new application's first run: an owner the error lists grants the `caller_user_uid`
-  `editor` on the namespace, or adds it to a Team that holds it, then the Job is
+- If reservation fails with `namespace_access_required` (403), the namespace already
+  exists: it is taken, or the Job was recreated with a new workload User. An owner the
+  error lists, or a manager of the workload that created the namespace, grants the
+  `caller_user_uid` `editor`, or adds it to a Team that holds it, then the Job is
   re-run. With `namespace_required`, set the table's namespace. With
   `table_not_editable`, an owner of the table or its namespace grants `editor`. Do
   not change code or physical names to get around it.

{mainsequence_metatable-0.1.47.dev76 → mainsequence_metatable-0.1.48.dev77}/.agents/skills/client/metatables-time-index-table-updates/SKILL.md

@@ -53,8 +53,8 @@ output binding or explicitly authorized row scope for mutation tests.
 
 A deployed producer runs as its Job's workload User. It needs `editor` on its output
 tables, which lets it operate updaters and write rows, and `data_viewer` on its
-inputs. Grant these on the namespaces, directly or through a Team, the same way and
-in the same order as the migration Job's `editor` (step 3 of the
+inputs. A person who manages the migration Job that created the output namespace, or
+an owner, grants these on the namespaces, directly or through a Team (step 3 of the
 [migrations skill](../metatables-migrations/SKILL.md)); no Organization admin is
 needed. Output tables belong to the migration provider and its namespace: a workload
 never creates a table outside a namespace.

{mainsequence_metatable-0.1.47.dev76/src/mainsequence_metatable.egg-info → mainsequence_metatable-0.1.48.dev77}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mainsequence-metatable
-Version: 0.1.47.dev76
+Version: 0.1.48.dev77
 Summary: Main Sequence MetaTables Python client and standalone API
 Author-email: Main Sequence GmbH <dev@main-sequence.io>
 License-Expression: MIT

{mainsequence_metatable-0.1.47.dev76 → mainsequence_metatable-0.1.48.dev77}/docs/adr/api/0024-namespace-and-table-access-roles.md

@@ -3,7 +3,8 @@
 Status: Accepted.
 
 Implementation status: implemented on development, in the API and in the MetaTables
-Admin's Access panels. Non-container tests pass. The container matrix passes on SQLite;
+Admin's Access panels. Namespaces created by a workload's registration (sections 3 and 5)
+are implemented in the API; the Admin does not yet label the `manager` source. Non-container tests pass. The container matrix passes on SQLite;
 on PostgreSQL, TimescaleDB, SQL Server and MySQL one runtime-bootstrap test fails, as it
 did before this change. Hosted deployment is pending. The user guides are
 [Ownership, roles, and inheritance](../../security/ownership-and-sharing.md) and the
@@ -52,8 +53,8 @@ instance contains namespaces, and a namespace contains tables.
 - A principal holds at most one binding per object; granting another role replaces
   it. Because roles are nested, its access is the strongest role among its own, its
   Teams' and its namespace's bindings. There is no explicit deny.
-- Organization admins, Team membership and namespace inheritance are **computed**, never
-  stored.
+- Organization admins, Team membership, namespace inheritance and the managers of a
+  namespace's creating workload are **computed**, never stored.
 - The API checks actions, never role names. One evaluator answers both single checks
   and list filters, so a list never shows what a check would refuse.
 - Each action has a level: `read` (see metadata), `use` (read data), `write` (change
@@ -206,6 +207,10 @@ workload Users, Teams.
 - A person who creates a namespace is granted `owner` on it (source `creator`). A taken
   name is refused and never adopted; the refusal names its owners when the caller may
   see them.
+- Registering a table into a namespace that does not exist creates it. A person who
+  does so is granted `owner`. A workload User is granted `editor`, and the namespace
+  records it as its **creating workload**: the people who manage that workload manage
+  the namespace's access. An existing namespace needs `tables.create`, whoever created it.
 - A person who creates a table outside any namespace is granted `owner` on it.
 - A table created in a namespace gets no binding: the namespace's roles cover it.
 
@@ -216,12 +221,17 @@ workload Users, Teams.
 | Every action on every object | Organization admin, from the platform on each request | `admin` |
 | The roles granted to a Team | the caller's current Team membership, from the platform | `team`, with the Team |
 | The table role of the same name | a role on the table's current namespace | `namespace`, with the namespace |
+| `namespaces.get`, `namespaces.get_access`, `namespaces.set_access` on a namespace | managing its creating workload, from the platform on each request | `manager`, with the workload |
+
+Managing the creating workload is access management only. It gives no role: no access
+to the namespace's tables, no `namespaces.update` and no table-level bindings.
 
 **Constraints** that no role overrides:
 
-- A workload User is never granted `owner`, never grants or revokes a role, never
-  creates a namespace and never creates a table outside a namespace. A Team holding
-  `owner` gives its workload members no access management.
+- A workload User is never granted `owner`, never grants or revokes a role and never
+  creates a table outside a namespace. It creates a namespace only by registering a
+  table into a free name, and then holds `editor`. A Team holding `owner` gives its
+  workload members no access management.
 - A non-admin grants roles only to Teams they belong to, checked with the platform at
   that moment, and to people and workload Users they can find in their own platform
   directory.
@@ -233,7 +243,9 @@ workload Users, Teams.
 
 1. hold `set_access` on the object and every action of the role on it (owners and
    admins always do); or
-2. manage the target workload User and hold every action of the role on the object.
+2. manage the target workload User and hold every action of the role on the object; or
+3. manage the namespace's creating workload: any role, `owner` included, on that
+   namespace.
 
 Revoking your own binding, and lowering or revoking a binding of a workload you manage,
 are always allowed. Revoking the last owner leaves the admins. Every grant and revoke is
@@ -264,45 +276,44 @@ tables and whose FastAPI `crm-api` reads and writes them. Nothing exists yet.
 ```text
  Ana (no admin role)                          MetaTables of the Environment
  ───────────────────                          ─────────────────────────────
- 1. create namespace crm  ──────────────────► namespace crm      Ana: owner (creator)
-    (namespaces.create, through member)
+ 1. push the workflow file ──► the platform creates migrate-crm and crm-api
+                               and their workload Users; Ana manages them
 
- 2. push the workflow file ──► the platform creates migrate-crm and crm-api
-                               and their workload Users
+ 2. deploy: migrate-crm  ───────────────────► namespace crm      migrate-crm: editor
+            registers its tables in crm                          (creating workload)
+                                              its tables (no binding of their own)
 
- 3. grant on crm  ──────────────────────────► migrate-crm: editor
-    (owner of crm)                            crm-api:     data_writer
-                                              directly, or to a Team
-                                              Ana belongs to that contains them
+ 3. grant on crm  ──────────────────────────► crm-api:     data_writer
+    (manages migrate-crm)                     Ana or a Team she belongs to: owner
 
- 4. deploy:  migrate-crm ───────────────────► creates its tables in crm
-                                              (no binding of their own)
-             crm-api     ───────────────────► reads and writes their rows
+ 4. crm-api  ───────────────────────────────► reads and writes their rows
 ```
 
-1. **Namespace.** Ana creates `crm` with `namespaces.create`, which every person holds
-   through `member`, and becomes its `owner`.
-2. **Workloads.** Applying the workflow file creates both workload Users before any of
-   its Jobs run.
-3. **Access.** As `owner`, Ana grants `editor` to the migration Job's workload User and
-   `data_writer` to the FastAPI's, either directly or through a Team she belongs to that
-   contains them.
-4. **Deploy.** The Job creates and migrates its tables; the FastAPI uses them.
+1. **Workloads.** Applying the workflow file creates both workload Users before any of
+   its Jobs run. The platform reports that Ana manages them.
+2. **Namespace and tables.** The first deployment's migration Job registers its tables
+   in `crm`. The namespace does not exist, so the registration creates it, grants the
+   Job `editor` and records it as the creating workload.
+3. **Access.** Because she manages `migrate-crm`, Ana manages `crm`'s access. She grants
+   `data_writer` to the FastAPI's workload User, and `owner` to herself or to a Team she
+   belongs to, so the namespace keeps an owner if the Job is recreated.
+4. **Use.** The FastAPI reads and writes rows; its requests before step 3 were refused,
+   and succeed on the next request after it, with no redeployment.
 
 This completes without an administrator:
 
-- Every step needs only `member`, held by every person, or the `owner` binding Ana
-  received in step 1.
-- A Team is optional. With direct bindings, a recreated workload's new User needs the
-  owner to grant its role again. With a Team, it needs only Team membership.
-- The workload Users exist only once step 2 applies the file. If the first migration
-  runs before step 3, it stops with `namespace_access_required`, naming the Job's
-  workload User, the namespace, the missing action and the namespace's owners; re-running
-  it after step 3 succeeds. If step 1 is missing, it stops with `namespace_not_found`.
+- Every step needs only the push, the registration in step 2, or managing the Job.
+- No namespace is created by hand, and the first migration succeeds.
+- A Team is optional. With direct bindings, a recreated workload's new User needs an
+  owner, or a manager of the creating workload, to grant its role again. With a Team,
+  it needs only Team membership.
+- A taken name stops the migration with `namespace_access_required`, naming the Job's
+  workload User, the namespace, the missing action and the owners when the Job may see
+  them. An owner grants the Job `editor`, or the application uses another namespace.
 - Least privilege holds from the start: the FastAPI writes rows but cannot migrate,
-  delete or share.
-- Each Environment has its own MetaTables. Another Environment repeats steps 1 and 3
-  there, done by someone the platform admits to it.
+  delete or share, and the Job never decides access.
+- Each Environment has its own MetaTables. The first deployment there creates the
+  namespace; step 3 is repeated by someone who manages the Job in that Environment.
 
 ### 6. API and clients
 
@@ -310,13 +321,15 @@ This completes without an administrator:
   texts. The role documentation is generated from it.
 - `POST /namespaces/` creates a namespace (replaces `POST /security/namespaces/`).
 - `GET /namespaces/{uid}/access/` and `GET /meta-tables/{uid}/access/` return the
-  bindings with their source, who granted each and when.
+  bindings with their source, who granted each and when. A namespace's document also
+  names its creating workload.
 - `POST .../access/changes/` grants and revokes roles in one request, checked against
   the access revision the caller read.
 - `GET .../access/me/` returns the caller's allowed actions; the Admin shows only the
   buttons they allow.
 - `GET .../access/explain/?user_uid=...&action=...` explains why someone can or cannot
-  do something.
+  do something. The `manager` source is shown only for the caller: the platform tells
+  only the caller which workloads they manage.
 - Removed: `PUT /meta-tables/{uid}/permissions`, `PUT /namespaces/{uid}/permissions`,
   `POST /security/namespaces/` and the Reader/Writer assignment documents.
 - The Python client gets `Namespace.create()`, `get_access()`, `grant_role()`,
@@ -337,7 +350,8 @@ One new system migration converts every grant, with no compatibility layer:
 | Namespace Writer | `editor` |
 | Namespace without an owner | none; admins hold it until they grant an owner |
 
-Access history is kept.
+Access history is kept. A second migration records each namespace's creating workload;
+existing namespaces have none, and their owners and admins manage them.
 
 ## Consequences
 
@@ -348,8 +362,11 @@ Access history is kept.
   that person's access.
 - A workload can no longer create a table outside a namespace. Updater Jobs that do so
   today must set a namespace.
-- Any person may claim a free namespace name. Admins can rename a namespace or change its
-  owners.
+- Any person, or a workload by registering a table, may claim a free namespace name.
+  Admins can rename a namespace or change its owners.
+- The people who manage a namespace's creating workload manage its access for as long as
+  the platform reports that they manage it. A namespace whose creating workload nobody
+  manages any more keeps its owners, and admins.
 - The catalog stores bindings instead of Reader/Writer flags, every route checks an
   action, and database reconciliation gains the admin role.
 - This amends ADR 0002 (namespace access is no longer admin-only; Reader/Writer become
@@ -363,5 +380,7 @@ Access history is kept.
 - The conversion migration on a catalog with every kind of existing grant.
 - The deployment of section 5 end to end as a non-admin, with direct bindings and with a
   Team; a recreated workload; a namespace name already taken.
+- A workload's registration creates the namespace with `editor`; a manager of the Job
+  grants any role; anyone else is refused.
 - In the database: `data_viewer` gets `SELECT` only; `data_writer` writes rows but its
   migration admission is refused; an admin reads a table without a binding.

{mainsequence_metatable-0.1.47.dev76 → mainsequence_metatable-0.1.48.dev77}/docs/client/deploy-application-migrations.md

@@ -15,13 +15,16 @@ before anything that uses the tables rolls out. See
    [Local storage](local-storage.md).
 2. **Commit the revision with the code that needs it.** Applied revisions are
    immutable; every later schema change is a new revision.
-3. **Give the Job access.** Before the first push to each Environment, create the
-   application's namespace; once the workload Users exist, grant them their roles
-   ([below](#give-the-job-access)). Any person can; no Organization admin is needed.
-4. **Deploy.** The application's workflow runs its migration Job from the
-   candidate image, then deploys the resources that read or write the tables.
-
-Hosted runtimes are migrated only by step 4. Do not run `metatables migrations
+3. **Deploy.** The application's workflow runs its migration Job from the
+   candidate image, then deploys the resources that read or write the tables. The
+   first deployment to an Environment creates the application's namespace there and
+   gives the Job `editor` on it.
+4. **Grant the other workloads.** Someone who manages the migration Job grants the
+   resources that read and write rows their roles on the namespace
+   ([below](#give-the-job-access)). Nobody creates the namespace by hand, and no
+   Organization admin is needed.
+
+Hosted runtimes are migrated only by step 3. Do not run `metatables migrations
 upgrade` or `downgrade` against a hosted API from a developer machine or agent
 session. Do not migrate at application startup either: several pods would race,
 and a failure would not stop the rollout.
@@ -111,48 +114,54 @@ against the branch's workflow template before committing it.
 
 ## Give the Job access
 
-The Job runs as its own workload User. Workloads never create namespaces, never grant
-roles, and create tables only inside a namespace where they hold `editor`
-([ADR 0024](../adr/api/0024-namespace-and-table-access-roles.md)). So a person sets up
-the application's access, once per Environment, and no Organization admin is needed.
-Do it in this order:
-
-1. **Before the first push, create the namespace.** Any person admitted to the
-   Environment can, in that Environment's MetaTables: with **Create namespace** on the
-   deployed Admin's Namespaces page, or with `Namespace.create("ledger")` from your own
-   session connected to that Environment
-   ([installation and connection](installation-and-connection.md)). You become its
-   `owner`. A name that is already taken is refused with its owners, when you can see
-   them; ask one of them for access instead.
-2. **Push the workflow file.** Applying it creates the Job, the FastAPI release and
-   their workload Users before any step runs. The first migration can run before
-   step 3 and stop with `namespace_access_required`; that is expected.
-3. **Grant the workloads their roles.** On the namespace's **Access** panel, find each
-   workload by its Job or release name and grant the migration Job `editor` and every
-   resource that only reads and writes rows, such as the FastAPI release, `data_writer`.
-   From Python, pass each resource's `workload_user_uid`, which the Main Sequence SDK
-   returns on the Job and the ResourceRelease.
-4. **Re-run the migration Job** if step 2's run was refused, or deploy again. It creates
-   the application's tables in the namespace; the tables need no grants of their own.
-
-Repeat steps 1, 3 and 4 in every Environment, each done by someone the platform admits
-to that Environment: each Environment has its own MetaTables and its own workload Users.
+The Job runs as its own workload User. A workload never grants roles and never creates
+a table outside a namespace ([ADR 0024](../adr/api/0024-namespace-and-table-access-roles.md)).
+It creates its namespace by registering its first table there:
+
+1. **Push the workflow file.** Applying it creates the Job, the FastAPI release and
+   their workload Users before any step runs.
+2. **The first migration creates the namespace.** When a provider's tables name a
+   namespace that does not exist in this Environment, the Job's registration creates
+   it and grants the Job `editor`. The namespace records the Job as its creating
+   workload. Later runs and new tables need nothing more.
+3. **Grant the other workloads, and an owner.** The people who manage the Job in the
+   platform manage the namespace's access. In that Environment's Admin, open the
+   namespace's **Access** panel, find each workload by its Job or release name, and
+   grant `data_writer` to every resource that only reads and writes rows, such as the
+   FastAPI release. Grant `owner` to yourself or to a Team you belong to, so the
+   namespace keeps an owner if the Job is recreated. From Python, pass each resource's
+   `workload_user_uid`, which the Main Sequence SDK returns on the Job and the
+   ResourceRelease. The FastAPI's requests are refused until then, and succeed on the
+   next request after the grant, with no redeployment.
+
+Repeat step 3 in every Environment, done by someone who manages the Job there: each
+Environment has its own MetaTables and its own workload Users.
 
 ```python
 from metatables import Namespace
 
-ledger = Namespace.create("ledger")                       # step 1: you become its owner
-ledger.grant_role(migration_job_workload_user_uid, "editor")   # step 3
-ledger.grant_role(api_workload_user_uid, "data_writer")
+ledger = next(n for n in Namespace.filter(search="ledger") if n.name == "ledger")
+ledger.grant_role(api_workload_user_uid, "data_writer")       # step 3
+ledger.grant_role(your_user_uid, "owner")
 ```
 
+Managing the Job lets you manage the namespace's access only: it gives you no access
+to its tables until you grant yourself a role.
+
 **Optionally, a Team.** Grant the roles to a Team you belong to instead of to the
 workload Users, and add the workload Users to that Team: any person can create a Team
 and, as its owner, add workloads they can view. A recreated Job or release then needs
 only Team membership, not a new grant. One Team can hold the roles in every Environment:
 Teams are Organization-wide, and a workload reaches only its own Environment's
 MetaTables. People in the Team receive the same roles, so leave it once the workloads
-are in if you should not hold them yourself; you stay the namespace's owner.
+are in if you should not hold them yourself.
+
+**A name that is already taken.** If the namespace already exists, created by another
+application, by a person or before this change, the first migration stops with
+`namespace_access_required`. An owner of that namespace grants the Job `editor`, or the
+application uses another namespace. A person may still create a namespace in advance,
+with **Create namespace** in the Admin or `Namespace.create("ledger")`, and grant the
+Job `editor`; nothing requires it.
 
 **Namespaces created before roles.** A namespace from before ADR 0024 has no owner: its
 former Writers hold `editor`. An Organization admin grants someone `owner` on it once;
@@ -188,18 +197,17 @@ the database.
 
 ### When registration is refused
 
-- **`namespace_not_found`**: the namespace does not exist in this Environment. Create
-  it (step 1) and grant the roles (step 3).
-- **`namespace_access_required`**: the namespace exists, but the `caller_user_uid` the
-  error names lacks `tables.create` on it. The error lists the namespace's owners when
-  the caller can see the namespace; one of them grants it `editor` (step 3). Expected
-  on a new application's first run.
+- **`namespace_access_required`**: the namespace already exists, but the
+  `caller_user_uid` the error names lacks `tables.create` on it. The error lists the
+  namespace's owners when the caller can see the namespace. One of them, or a manager
+  of the workload that created the namespace, grants it `editor`. A recreated Job gets
+  this too: its new workload User has no role yet.
 - **`namespace_required`**: a workload tried to create a table outside any namespace.
   Set the table's namespace.
 - **`table_not_editable`**: the table already exists and the caller lacks
   `tables.update` on it. An owner of the table or its namespace grants `editor`.
 
-After the grant, re-run the Job (step 4). Do not run the Job as an Organization admin
+After the grant, re-run the Job. Do not run the Job as an Organization admin
 or change physical names to get around a refusal.
 
 ## What the Job guarantees
@@ -213,8 +221,8 @@ or change physical names to get around a refusal.
 - The Job finds the Environment's MetaTables API the same way any client does
   ([installation and connection](installation-and-connection.md)). That API must
   be deployed with its system migrations applied; otherwise the Job fails. Its
-  workload User needs `editor`, directly or through a Team, on every namespace the
-  provider creates tables in.
+  workload User needs `editor`, directly or through a Team, on every existing
+  namespace the provider creates tables in; a namespace it creates gives it `editor`.
 
 ## Keep each release compatible with the previous one
 

{mainsequence_metatable-0.1.47.dev76 → mainsequence_metatable-0.1.48.dev77}/docs/concepts/permissions-namespaces-labels.md

@@ -14,8 +14,11 @@ every action, data included.
 ## Namespaces
 
 A catalog namespace groups tables for access. Any person can create a namespace whose
-name is free and becomes its owner. A namespace is visible to whoever holds a role on
-it or can see at least one of its tables; counts show visible tables only. A role on a
+name is free and becomes its owner. Registering a table into a missing namespace also
+creates it: a person owns it; a workload gets `editor`, and the people who manage that
+workload manage the namespace's access. A namespace is visible to whoever holds a role
+on it, can see at least one of its tables, or manages its creating workload; counts
+show visible tables only. A role on a
 namespace gives the table role of the same name on its current and future tables.
 Revoking it, or moving a table out, removes that contribution; independent direct or
 Team bindings remain. Moving a table needs `tables.update` on the table and

{mainsequence_metatable-0.1.47.dev76 → mainsequence_metatable-0.1.48.dev77}/docs/security/index.md

@@ -4,8 +4,10 @@ MetaTables separates **application administration** from **access to namespaces
 and tables**. Organization admins configure the application and hold every action.
 Everyone else gets access through **roles** granted on a namespace or a table:
 `metadata_viewer`, `data_viewer`, `data_writer`, `editor` and `owner`. Any person can
-create a namespace or a table and owns what they create. Nobody needs to become an
-Organization admin to deploy an application or maintain its tables.
+create a namespace or a table and owns what they create. A deployed migration Job
+creates its application's namespace on its first run, and the people who manage the
+Job manage that namespace's access. Nobody needs to become an Organization admin to
+deploy an application or maintain its tables.
 
 The API enforces this model in both local and hosted runtimes. The Admin UI and
 Python client use the same access endpoints. [ADR 0024](../adr/api/0024-namespace-and-table-access-roles.md)
@@ -92,7 +94,8 @@ These are browser routes. Resource API URLs remain unchanged and enforce their
 own permissions: DataSource mutations and validation, runtime configuration and
 selection, system migrations, local database destruction, external imports and
 global Security operations require admin admission. Granting roles on a namespace or
-table is available to its owners.
+table is available to its owners, and on a namespace also to the managers of the
+workload that created it.
 
 Every operation is enforced by the API, including requests from the Python client.
 The UI shows the API's effective permissions. Hidden buttons are a presentation

{mainsequence_metatable-0.1.47.dev76 → mainsequence_metatable-0.1.48.dev77}/docs/security/ownership-and-sharing.md

@@ -13,10 +13,16 @@ principals can be owners. `created_by_user_uid` records who created a table and
 grants nothing. Organization admins hold every action on every object, so a
 namespace or table never ends up without someone who can manage it.
 
-Workload Users never create namespaces, never create tables outside a namespace and
-are never granted `owner`. A deployed Job, release or Agent creates its tables in a
-namespace where it holds `editor`, usually through a Team. See
-[Namespaces and applications](#namespaces-and-applications).
+Registering a table into a namespace that does not exist creates it. A person who does
+so owns it. A workload User gets `editor` instead, and the namespace records it as its
+**creating workload**: the people who manage that Job, release or Agent in the platform
+manage the namespace's access. They can see the namespace and its bindings and grant
+or revoke any role on it, `owner` included, but get no access to its tables until they
+grant themselves a role.
+
+Workload Users never create tables outside a namespace, never grant roles and are never
+granted `owner`. An existing namespace needs `editor` from its owners, its creating
+workload's managers or a Team. See [Namespaces and applications](#namespaces-and-applications).
 
 ## Roles and bindings
 
@@ -154,9 +160,9 @@ see.
 What MetaTables enforces:
 
 - **Creating a table in a namespace** needs `tables.create` on it (`editor` or
-  `owner`). A missing namespace is refused with `namespace_not_found`; a namespace
-  without that action with `namespace_access_required`, naming the caller, the action
-  and, when visible, the namespace's owners.
+  `owner`). A missing namespace is created by the registration. An existing one
+  without that action is refused with `namespace_access_required`, naming the caller,
+  the action and, when visible, the namespace's owners.
 - **Reading or writing a table** needs `tables.get_data` or `tables.update_data`
   through a role on the table or its namespace. The API checks it, and the database
   enforces it through the caller's own role
@@ -169,16 +175,14 @@ tables without a namespace.
 
 ### Recommended: one namespace per application
 
-1. Before the first push, a person creates the application's namespace, for example
-   `crm`, and becomes its owner.
-2. Pushing the workflow file creates the workload Users. The owner grants `editor` to
-   the migration Job's workload User and `data_writer` to the workload Users that only
-   read and write rows, or grants these roles to a Team they belong to that contains
-   those workloads.
-3. The migration Job creates and migrates the application's tables in `crm`. If its
-   first run came before step 2, re-run it.
+1. Pushing the workflow file creates the workload Users.
+2. The first deployment's migration Job registers its tables in `crm`, which creates
+   the namespace and gives the Job `editor`.
+3. A person who manages the Job grants `data_writer` to the workload Users that only
+   read and write rows, and `owner` to themselves or to a Team they belong to. They can
+   instead grant these roles to a Team that contains the workloads.
 
-This needs no Organization admin. A Team is optional: it saves granting again when a
+This needs no Organization admin and no namespace created by hand. A Team is optional: it saves granting again when a
 workload User changes. Teams are Organization-wide and a workload reaches only its
 own Environment's MetaTables, so one Team can hold the application's roles in every
 Environment's catalog. Another application gets read access through one `data_viewer`
@@ -189,6 +193,8 @@ binding on the namespace; revoking it removes access to every table at once. See
 
 Every namespace and table has an **Access** panel. It lists each binding with its
 role, its texts, its source (direct, Team, namespace, admin), who granted it and when.
+A namespace's panel also names its creating workload; if you manage it, your access
+shows the source `manager`.
 Owners grant, change and revoke roles there; granting shows the role's texts before it
 is confirmed. **Explain** shows why a chosen User can or cannot do an action, and
 **access history** shows past changes. Buttons follow the caller's allowed actions
@@ -220,8 +226,8 @@ and review intervening changes.
 | --- | --- |
 | `GET /access/roles/` | Any caller |
 | `POST /namespaces/` | Any person (`namespaces.create`); never a workload |
-| `GET /meta-tables/{uid}/access/`, `GET /namespaces/{uid}/access/` | `get_access` on the object |
-| `POST /meta-tables/{uid}/access/changes/`, `POST /namespaces/{uid}/access/changes/` | `set_access`, or a workload's manager for that workload; never a workload |
+| `GET /meta-tables/{uid}/access/`, `GET /namespaces/{uid}/access/` | `get_access` on the object, or a manager of the namespace's creating workload |
+| `POST /meta-tables/{uid}/access/changes/`, `POST /namespaces/{uid}/access/changes/` | `set_access`, a manager of the namespace's creating workload, or a workload's manager for that workload; never a workload |
 | `GET .../access/me/` | Any caller who can see the object |
 | `GET .../access/explain/?action=...&user_uid=...` | Yourself: anyone who can see the object; another User: `get_access` |
 | `GET /meta-tables/{uid}/access-history/` | `tables.get_access` |

{mainsequence_metatable-0.1.47.dev76 → mainsequence_metatable-0.1.48.dev77}/docs/security/permissions.md

@@ -23,9 +23,10 @@ Organization admin status comes from the platform through the SDK.
 | Discover and import external tables and views | No | Yes |
 | Every action on every namespace and table, data included | No | Yes |
 
-Workload Users are not `member`s: they never create namespaces, never create tables
-outside a namespace, and never grant or revoke roles. They use the roles granted to
-them or to their Teams.
+Workload Users are not `member`s: they never create tables outside a namespace and
+never grant or revoke roles. A workload creates a namespace only by registering a table
+into a free name, and then holds `editor` on it. They use the roles granted to them or
+to their Teams.
 
 Initial runtime setup must check the platform admin fact before the application
 catalog exists. Configuring a pending database does not make the first caller an
@@ -44,6 +45,11 @@ admin.
 A namespace role also gives the table role of the same name on every table currently
 in the namespace, including tables created later.
 
+The people who manage a namespace's creating workload hold `namespaces.get`,
+`namespaces.get_access` and `namespaces.set_access` on it, with no role. They may grant
+any role there, `owner` included, but they get no table actions and change no
+table-level bindings.
+
 ## Table actions and roles
 
 | Action | `metadata_viewer` | `data_viewer` | `data_writer` | `editor` | `owner` |

{mainsequence_metatable-0.1.47.dev76 → mainsequence_metatable-0.1.48.dev77}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "mainsequence-metatable"
-version = "0.1.47.dev76"
+version = "0.1.48.dev77"
 description = "Main Sequence MetaTables Python client and standalone API"
 readme = "README.md"
 requires-python = ">=3.13"

{mainsequence_metatable-0.1.47.dev76 → mainsequence_metatable-0.1.48.dev77/src/mainsequence_metatable.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mainsequence-metatable
-Version: 0.1.47.dev76
+Version: 0.1.48.dev77
 Summary: Main Sequence MetaTables Python client and standalone API
 Author-email: Main Sequence GmbH <dev@main-sequence.io>
 License-Expression: MIT