Plugin group config in group requests#548
Draft
somethingnew2-0 wants to merge 3 commits into
Draft
Conversation
Add two JSON columns to GroupRequest -- requested_plugin_data (supplied with the
request) and resolved_plugin_data (a resolver-editable copy) -- mirroring the
existing requested_*/resolved_* pairs, plus the Alembic migration. Config is
stored in the same shape as a group's plugin_data ({plugin_id: {configuration:
{...}}}); no status is kept, since the lifecycle hook populates that after the
group is created. Surface both on GroupRequestDetail, requested_plugin_data on
the app-group create body, and resolved_plugin_data on the resolve body.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Let a requester supply app-group-lifecycle plugin config when requesting an app group, and a resolver edit it before approval, so the group created on approval is configured and the plugin's group_created hook runs against it: - CreateGroupRequest persists requested_plugin_data; the POST router validates it against the app's plugin (400 on invalid/missing-required). - ApproveGroupRequest resolves resolved_plugin_data or requested_plugin_data, re-validates it defensively (the app/config may have changed since filing), and sets it on the new AppGroup *before* CreateGroup runs so group_created sees the configured group. - The resolve (PUT) handler copies resolved_plugin_data so a resolver can edit before approving. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Render the existing AppGroupLifecyclePluginConfigurationForm for app-group requests whose target app has a lifecycle plugin: the create dialog submits requested_plugin_data, and the resolver's read view pre-fills with the requester's config and submits resolved_plugin_data. Small DOM-free helpers (pluginConfig.ts) with unit tests. Regenerate the API client for the new request plugin_data fields. Also fix a pre-existing jest-dom v6 import in setupTests.ts (the /extend-expect subpath was dropped) so the frontend test suite runs. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Takes over and rebases #502 (originally by @barborico) onto current
main.What
Lets a requester supply app-group-lifecycle plugin group config when requesting an app group, and a resolver edit it before approval, so the group created on approval is already configured and the plugin's
group_createdhook runs against a configured group. Today that config is only collectable in the direct group create/edit flow, so approving a requested group leaves it unconfigured.GroupRequest(requested_plugin_data,resolved_plugin_data) mirroring the existingrequested_*/resolved_*pairs, plus a migration. Stored in the same shape as a group'splugin_data; no status is kept (the hook populates that post-creation).CreateGroupRequestpersists the requested config; the POST route validates it against the app's plugin (400 up front).ApproveGroupRequestresolves resolved-over-requested, re-validates defensively, and sets it on the newAppGroupbeforeCreateGroupruns. The resolve (PUT) route lets a resolver edit it.This is a generic capability — it works with any app-group-lifecycle plugin, not a specific one.
Rebase notes
Like #498, #502 predates the async-SQLAlchemy migration (#480/#481), the
uv/tytoolchain (#507), the async plugin interface (#511), the Okta SDK v3 upgrade (#509), and theapi/manage.py→api/cli.pyrename (#520). This branch is a fresh, async-native re-application onto currentmain: the group-request operations/router additions were fit to the awaited async paths (e.g.await db.session.get(...)in approval), the migration'sdown_revisionwas re-pointed to the current head, and the generated client was regenerated. It is independent of the #498/#532 rebase (a sibling, not stacked) — it builds only on plugin-config infrastructure already onmain.Complements #532 (the Google group manager plugin) but does not depend on it; the two overlap only trivially (the generated client and a one-line
setupTests.tsfix). See #502's original description for the functional walkthrough.Rebase and async conversion by Claude; original design and implementation by @barborico in #502.
🤖 Generated with Claude Code