Skip to content

feat(deployments): auto-resolve course groups on deployment create - #170

Merged
Dilmand merged 1 commit into
stagingfrom
feat/auto-resolve-course-groups
Jun 29, 2026
Merged

feat(deployments): auto-resolve course groups on deployment create#170
Dilmand merged 1 commit into
stagingfrom
feat/auto-resolve-course-groups

Conversation

@Dilmand

@Dilmand Dilmand commented Jun 29, 2026

Copy link
Copy Markdown
Contributor

Summary

Moves course_groups get-or-create out of the frontend wizard and into DeploymentService.create_deployment. For every group referenced by the incoming stack_assignments, the service now:

  1. Looks up an existing CourseGroup row by (course_id, name), or creates one if missing.
  2. Backfills course_group_id on the request payload when the client passed null, so deploy_tasks can stamp the FK onto DeploymentInstanceAccess rows.

Motivation

Previously, the wizard had to:

  • resolve the internal courses.id for the selected Keycloak group via GET /courses,
  • pre-create course_groups rows via POST /courses/{id}/groups before submitting the deployment.

That flow had two failure modes:

  1. On the very first deployment of a course (no courses row yet, no course_groups rows yet), the wizard couldn't resolve the internal course id and submitted course_group_id: null. Credential rows then had group_id = NULL and students lost visibility via /api/v1/student/.
  2. If the wizard's course_groups bootstrapping hit an HTTP error, it aborted the deployment with a user-facing toast — even though the backend already had Course get-or-create logic and was capable of doing the same for groups.

Doing this server-side guarantees that course_group_id is always populated, regardless of which client submits the deployment.

Changes

  • src/services/deployment_service.py: after the existing Course get-or-create, build a {group_name: course_group_id} map for the course; create missing CourseGroup rows; backfill course_group_id on any stack_assignments[].groups[] entry that arrived with None.

Companion PR

  • Frontend: DoziLab/appstore-frontendrefactor/move-course-group-resolution-to-backendstaging

Test plan

  • Deploy a brand-new course (no prior courses or course_groups rows) — confirm course_groups rows are auto-created and DeploymentInstanceAccess.group_id is non-null.
  • Deploy into an existing course — confirm existing course_groups are reused (no duplicates), names are matched case-sensitively as before.
  • Deploy with a client that still sends a populated course_group_id (older frontend build) — confirm the value is honoured, not overwritten.

Move course_groups get-or-create out of the frontend wizard and into
DeploymentService. For every group referenced by the incoming stack
assignments we now look up an existing CourseGroup by (course_id, name)
or create one, and backfill course_group_id on the request payload so
deploy_tasks can stamp the FK onto DeploymentInstanceAccess rows.

This guarantees students see their credentials via /api/v1/student/
even on the very first deployment of a course — previously the wizard
had to bootstrap the course_groups rows itself, which could fail and
either abort the deploy or leave group_id NULL on credential rows.
@Dilmand
Dilmand merged commit 186dbfe into staging Jun 29, 2026
6 checks passed
@Dilmand
Dilmand deleted the feat/auto-resolve-course-groups branch June 29, 2026 16:35
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