Skip to content

CI: access-groups stack (fork-internal, do not merge) - #1

Draft
TheLiberal wants to merge 4 commits into
mainfrom
access-groups/3-console-ui
Draft

CI: access-groups stack (fork-internal, do not merge)#1
TheLiberal wants to merge 4 commits into
mainfrom
access-groups/3-console-ui

Conversation

@TheLiberal

Copy link
Copy Markdown
Owner

Fork-internal draft PR to run CI on the full access-groups stack under this fork's own Actions. The real PRs are upstream (UsefulSoftwareCo/executor UsefulSoftwareCo#1597-UsefulSoftwareCo#1599). Do not merge.

Tenant-scoped access_group/access_group_member tables plus a nullable
connection.access_group column. A restricted org connection is invisible
and uninvokable for non-members on every read and invoke surface, with
no existence oracle; membership is read live per call. Management rides
executor.accessGroups behind host admin gates (cloud /org/access-groups*,
self-host /api/admin/access-groups*), never the any-member ExecutorApi.
Platform view and subject-less org bindings stay unfiltered by design.
The cascade tripwire caught the gap: the hand-written purge list must name
every tenant table, and access_group/access_group_member were missing.
A toolkit granted to a group exists only for its members: the slug
resolves to nothing for anyone else (toolkit MCP sessions block-all,
identical to an unknown slug) and its CRUD reads answer not-found.
Grants are managed through the extension's setAccessGroup, exposed only
on the host admin planes; the group-deletion path refuses to orphan a
toolkit grant. Plugins gain a read-only core seam
(accessGroups.visibleGroupIds) to apply the same restricted-is-invisible
rule core applies to connections.
A shared admin page at /access-groups (the /users pattern): groups CRUD,
a member roster joined to /account/members identities with a picker, and
the connection/toolkit restriction lists with a restrict-connection
dialog. The API definition moves into @executor-js/api with both hosts
serving identical /admin/access-groups* routes, so ONE shared client and
atom set works everywhere; cloud additionally gains the mount on its
production extension-routes root. The access-groups segment joins the
reserved org slugs so no org can shadow the console route.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant