Plugin group config in group requests

[barborico]

Summary

Lets users supply (and resolvers edit) app-group-lifecycle plugin group config when requesting an app group, validates it at submit and approval, and applies it to the group created on approval so the plugin's group_created hook runs against a configured group.

Urgency: 5 days
Expected review effort: MEDIUM

Motivation

App-group-lifecycle plugins can require per-group config (e.g. the Google Group plugin needs an email prefix + display name). Today that config is only collectable in the direct group-create/edit flow. When a user requests a group for such an app, there is nowhere to supply it, so approval creates the group unconfigured and the group_created hook runs against an empty config. This adds a generic "plugin-config-in-requests" capability (not specific to any one plugin).

Description of Changes

• Model + migration: two JSON columns on GroupRequest — requested_plugin_data and resolved_plugin_data — mirroring the existing requested_*/resolved_* pairs and the sibling *_group_tags columns (JSONB on Postgres, server_default "{}"). Config is stored in the same shape as a group's plugin_data ({plugin_id: {configuration: {...}}}); no status is stored (the hook populates that post-creation).
• Schemas: requested_plugin_data on the app-group create body; both fields on GroupRequestDetail; resolved_plugin_data on ResolveGroupRequestBody.
• Create: CreateGroupRequest persists requested_plugin_data; the POST router validates it against the app's plugin (400 on invalid/missing-required).
• Approve: ApproveGroupRequest resolves resolved_plugin_data or requested_plugin_data, re-validates, and sets it on the new AppGroup before CreateGroup runs, so the group_created hook sees the configured group. Invalid config surfaces as a 400 via the PUT handler.
• Resolve (PUT): copies resolved_plugin_data from the resolve body so a resolver can edit before approving.
• Frontend: Create.tsx renders the existing AppGroupLifecyclePluginConfigurationForm for app-group requests whose app has a plugin (fetching AppDetail via useAppById since search summaries omit the plugin id) and submits requested_plugin_data; Read.tsx lets the resolver edit and submits resolved_plugin_data. Small DOM-free helpers (pluginConfig.ts) with unit tests.
• Generated client: the plugin_data fields were hand-added to src/api/apiSchemas.ts. A full npm run codegen in this environment renames the paginated generics (PageTypeVarCustomized* → PageTCustomized*) across the entire client, which would bury this change under hundreds of unrelated lines; the drift-check workflow sanctions hand-editing the generated files.
• Also fixes a pre-existing one-liner in src/setupTests.ts (jest-dom v6 dropped the /extend-expect subpath), which is required for the frontend test suite to run.

Validation of Changes

• Backend: tests/test_group_request_plugin_config.py covers column defaults/round-trip, schema parsing, CreateGroupRequest persistence, POST 400-on-invalid + 201-on-valid, approval applying resolved-over-requested onto the created group (asserting the group_created hook fired against it) + fallback-to-requested, and the PUT resolve path end-to-end. Full relevant suite: 134 passed (test_group_request, test_group_request_plugin_config, test_app_group_lifecycle_plugin, test_request_models).
• Migration verified up + down on a scratch SQLite DB.
• Frontend: npx tsc --noEmit clean; pluginConfig.test.ts 5/5.
• Manual UI check: confirm the resolver form in Read.tsx pre-fills with the requester's submitted config (the form seeds via uncontrolled defaultValue).

Guidance for Reviewers

Review commit-by-commit — the history is linear and each commit is one logical layer (model → migration → schemas → create op → POST validation → approve op → PUT → client → Create form → Read form). Most worth a look: ApproveGroupRequest setting new_group.plugin_data before CreateGroup.execute() (so the hook sees it), and the hand-edited TS client (see the codegen-churn rationale in that commit).

🤖 Generated with Claude Code