Four findings from the first review round.
`workspaceGroupNames` reads workspace `group_` rows, which is what an identity
rule resolves against, but an owner or an ACL entry is matched against the
caller's `authed.groups` — and `get_groups_for_user` unions `email_to_igroup`
into that. An instance group is instance-wide, so `g/<igroup>` grants access in
the target exactly as it did in the source, yet the translator dropped it on
every deploy and reported it as having "no account in the target".
The two therefore resolve against different sets: `translateAccess` takes
`group_ ∪ instance_group` (`listGroupNames`, unpaginated server-side) and
`translateRule` keeps `group_` alone, since `ensure_permissioned_as_exists`
rejects an instance group — a folder created with one as its rule is accepted by
`create_folder` and then refuses every item created in it.
Owners are omitted rather than sent as `[]` when every one of them is
untranslatable. `update_folder` force-appends the caller only when they are not
an admin, so an admin deploying such a folder would have left it with no owners
at all; omitting the key keeps whatever the target had, and on create the server
appends the caller regardless.
`labels` now mirrors the source like `default_permissioned_as` does, rather than
preserving the target's. One of the two had to give, and a label or rule cleared
at the source has to clear in the copy.
`workspaceGroupNames` stops on a short page again. The concern that motivated
removing it — an instance capping `per_page` below the 1000 asked for — cannot
happen: `list_groups` runs through `paginate()`, which caps at `MAX_PER_PAGE`
(10000). The size check stays as the backstop for a server that ignores `page`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Guilhem Lemouel
9800051b00