Read groups from the groups service, and tag apps with community IDs

[johnworth]

Part of the Grouper removal: apps reads groups from the new groups service. It depends on that service being deployed, so it merges in the cutover window alongside the PRs listed under Ordering.

apps.clients.iplant-groups becomes apps.clients.groups. Groups are addressed by structured identity (group_type plus name) rather than by colon-delimited Grouper paths, so the name-packing helpers go, along with the cyverse-groups-client dependency.

Scope

22 call sites across 11 files — not the 11 an earlier audit reported. The client is required under three aliases (ipg, groups, groups-client), so any single-alias search misses about two-thirds of them. Keeping every function's name, arity, and response shape meant all but three call sites are untouched.

File	Calls	Alias
clients/permissions.clj	5	ipg
service/groups.clj	4	ipg
clients/notifications/common_sharing.clj	2	ipg
clients/notifications.clj	2	groups-client
service/apps/job_listings.clj	2	ipg
service/apps/tapis/listings.clj	2	ipg
service/apps/communities.clj	1	groups
service/workspace.clj	1	ipg
user.clj	1	ipg
service/apps/de/jobs/common.clj	1	ipg
service/apps/tapis/sharing.clj	1	ipg

The three that changed

user_groups in the job submission was the one call site that depended on Grouper's colon-path naming, via remove-environment-from-group. It is now the plain group names. The field is inert either way — apps computes it and model carries it, but nothing reads it: FormatUserGroups has no callers outside its own tests.

grouper-user-group-id → de-users-group-id, resolving through /groups/lookup rather than building a Grouper path.

The workshop group response drops Grouper's type, extension, display_extension, and id_index in favour of group_type, and its schema moves with it. terrain proxies these admin endpoints; no browser code consumes them.

Community admins now match admin or own

The importer only ever produces admin for a community — ownerGrant returns nil where there is no owner segment. But a community created natively grants own to whoever created it, and that person administers it. Filtering on admin alone would lock a community's own creator out of tagging apps into it.

Verified on the local cluster

Against real imported Grouper data, with the groups and permissions services on their migration branches:

• de-users-group-id resolves to the preserved Grouper UUID 1e01485adf464393835b808b3bab09af, and /apps used it to mark 2 of 3 apps public — the full chain through the groups service to the permissions service.
• Workshop group create/read/update works, including lazy creation. The new group's ID is 32-hex undashed, matching the shape of imported IDs.
• Community authorization: a non-admin gets 403 "User is not an admin of that community"; the holder of admin succeeds.
• /analyses and /apps listings return normally (these exercise lookup-subject-groups).

Not exercised locally: the notification and Tapis listing paths (Tapis is disabled there and there is no sharing traffic). They use lookup-subject and lookup-subjects, both of which other paths did exercise.

lein check is clean and the suite passes (81 tests, 217 assertions).

Community tags now name a community by ID

This also carries the community-tag change, because the two are inseparable: the tag value is a community name, and this branch is what makes names resolvable to IDs.

The stored value is now the community's ID, and callers send {"community_ids": [...]} rather than composing an AVU. Identifiers are resolved on both the read and write paths, so an ID, a short name, and a legacy colon path all select the same community — which is what lets a browser holding a pre-cutover bundle keep working instead of 404ing. DELETE /apps/:app-id/communities/:community-id joins the body-based form.

The important fix is on the admin route. community-admin-update-avus skipped validate-avu-community-admins entirely when admin? was true, so nothing looked at the value at all and an unresolvable one was written straight through to the metadata service — a tag no listing could ever match. That is the mechanism behind the 17 orphaned tag values in production. Administrators still bypass the community-admin check; they no longer bypass resolution.

Measured against a local cluster before and after:

Route	Value posted	Before	Now
admin	iplant:de:de:communities:Vanished	200, orphan written	404
user	iplant:de:de:communities:Imaging	404	200, stores the ID
user	community_ids: [<id>]	—	200
user, non-admin	any	403	403

Both halves are pinned by tests that fail when the old behaviour is reintroduced — verified by reintroducing it.

The one-off rewrite of existing tags is a command in the groups repo rather than a migration, because the mapping spans two databases; see cyverse-de/deployments#86.

Not addressed here

apps/user.clj:55-56 reads :first-name/:last-name from the subject lookup, but that service returns first_name/last_name — and did before this change too. Those have been nil since at least 2021, so integration-data and private-tool implementor names are built from empty strings. Orthogonal to this migration; worth its own issue.

Ordering

The image builds in-container against the released common-swagger-api 3.4.22 (cyverse-de/common-swagger-api#101, released to Clojars and pinned in project.clj) and is deployed and verified on a local cluster.

• common-swagger-api — 3.4.22 released and pinned
• Groups service client, behind the terrain.groups.backend toggle terrain#333 — passes the new shape through
• Identify collections by ID when tagging apps sonora#723 — sends IDs
• Deploy the groups service, the Grouper importer, and the apps/group-propagator cutover config deployments#86 — deployment config and the data migration