Support program-specific pathway schools in learner record sharing

[AhtishamShahid]

Closes mitodl/hq#12321

This pull request introduces program-specific pathway school assignments, allowing each program to be linked to specific partner schools and enabling per-program recipient addresses for learner record sharing. The changes are carefully feature-flagged to preserve legacy behavior until the new logic is enabled. Major updates span the admin interface, API, mail delivery, and test coverage.

These changes lay the groundwork for program-specific pathway school sharing, while ensuring that no behavioral changes occur until the feature flag is enabled.

Feature flag

Flag: mitxonline-12321-program-specific-pathway-schools, ships off.

Two functions read it, both deliberate and both commented:

• courses.api.partner_schools_for_program — the learner's dropdown and the share endpoint's validation
• courses.mail_api.send_partner_school_sharing_message — recipient routing

Gating mail matters because assignments are entered before the flip. Without it, a mistyped address among ~122 hand-entered rows would receive a real learner record — name, email, grades — while the flag still claimed nothing had changed.

With the flag off, the set of schools shown and accepted is unchanged, and the email recipient is unchanged, whether or not any assignments have been entered.

pathway-schools-walkthrough.mp4

---

Rollout checklist

• Create the flag mitxonline-12321-program-specific-pathway-schools in PostHog, off
• Confirm whether production runs POSTHOG_ENABLED=True. If not, the flag falls back to the FEATURES env var, and the name must be FEATURE_mitxonline-12321-program-specific-pathway-schools — get_features() strips the FEATURE_ prefix and uses the remainder verbatim, so the hyphens are required and an underscored name silently never matches
• Product enters assignments for all five programs (DEDP, SCM, SDS, PoM, Finance) at /admin/courses/partnerschool/
• Spot-check a multi-program school (MIT) has the right address per program
• Verify a DEDP record and an SCM record show different lists
• Open a follow-up ticket to delete the flag and both if is_enabled(...) branches

[github-actions]

OpenAPI Changes

Show/hide changes

## Changes for v0.yaml:
No changes detected

## Changes for v1.yaml:
No changes detected

## Changes for v2.yaml:
No changes detected

Unexpected changes? Ensure your branch is up-to-date with main (consider rebasing).

[Copilot]

Pull request overview

Adds support for program-specific “pathway school” assignments when learners share program records, including per-program recipient routing and validation, shipped behind a new feature flag (default OFF) to preserve existing behavior until rollout.

Changes:

• Introduces PartnerSchoolProgram through model to link partner schools to programs with per-program recipient email(s) (and alt_email stored for reference only).
• Filters/validates learner-visible partner schools via a shared helper (partner_schools_for_program) and rejects sharing to non-assigned schools when the flag is ON.
• Updates email sending to support multiple recipients (one email per recipient) when the flag is ON, plus extensive test coverage and admin UI for assignment entry.

Reviewed changes

Copilot reviewed 17 out of 17 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
main/features.py	Adds the ENABLE_PROGRAM_SPECIFIC_PATHWAY_SCHOOLS feature flag constant.
drf_lint_baseline.json	Updates baseline line references after serializer changes.
courses/views/v1/views_test.py	Adds endpoint-level tests for program-scoped validation and partner school filtering behavior.
courses/views/v1/init.py	Adds optional ?program= filtering to partner schools endpoint and enforces program-scoped school validation for record sharing.
courses/serializers/v1/programs.py	Routes partner school serialization through the shared helper to keep dropdown + validation consistent.
courses/serializers/v1/programs_test.py	Adds serializer tests for program-specific filtering, ordering, deduplication, and flag-off behavior.
courses/models.py	Adds PartnerSchoolProgram model, PartnerSchool↔Program M2M through it, alphabetical ordering, and recipient resolution helper.
courses/models_test.py	Adds unit tests for per-program recipient resolution, alt-email non-usage, and default ordering.
courses/migrations/0101_partnerschoolprogram.py	Creates the new through table, index, constraint, and ordering state change.
courses/mail_api.py	Adds feature-flag-gated per-program recipient routing and multi-recipient sending.
courses/mail_api_test.py	Adds mail routing tests for per-program, multi-recipient, alt-email exclusion, fallback, and flag-off behavior.
courses/factories.py	Adds PartnerSchoolProgramFactory for test data creation.
courses/api.py	Adds partner_schools_for_program helper with feature-flag gating and deduplication via distinct().
courses/api_test.py	Adds API helper tests for flag-on filtering, flag-off behavior, and deduplication.
courses/admin.py	Adds admin inline and changelist enhancements for program assignments and filtering.
courses/admin_test.py	Adds admin tests ensuring inline presence and changelist filtering by program.
conftest.py	Defaults the new feature flag to OFF in tests.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 17 out of 17 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

courses/models.py:2739

• PartnerSchool now has a global Meta.ordering = ["name"], which changes the default ordering for all PartnerSchool.objects... queries immediately (including when ENABLE_PROGRAM_SPECIFIC_PATHWAY_SCHOOLS is off). This appears to contradict the PR description’s claim that legacy behavior is preserved until the feature flag is enabled, and could affect any existing API/UI consuming partner schools where ordering was previously insertion/PK-based.

Consider either (a) gating ordering changes behind the feature flag (e.g., apply an explicit .order_by("name") only in the flagged code paths) or (b) updating the PR description/rollout expectations to acknowledge the behavior change if the new ordering is intentional.

    class Meta:
        ordering = ["name"]

[dsubak]

You may still want a subject matter expert to take a look, but once I was able to populate some of the requisite records, I was able to exercise the user facing and admin behaviors in the video and everything looked good to me!

[AhtishamShahid]

You may still want a subject matter expert to take a look, but once I was able to populate some of the requisite records, I was able to exercise the user facing and admin behaviors in the video and everything looked good to me!

Hi , @pdpinch I need a second review on this from someone who can take a look at it from a product point of view. Thanks.

[pdpinch]

How will you migrate existing data in mitxonline?

This looks good to me from a product point of view. I'd like to take another look at the admin once it's on RC, but I think this will work well -- better than I expected, TBH.

[AhtishamShahid]

How will you migrate existing data in mitxonline?

This looks good to me from a product point of view. I'd like to take another look at the admin once it's on RC, but I think this will work well -- better than I expected, TBH.

This requires manual data entry, i.e from the provided CSV files in the ticket to the Django admin.

[AhtishamShahid]

@pdpinch Please let me know if I should merge it or if there are any other concerns about it

[pdpinch]

Yes, let's merge. Let me know when it's on RC so I can do some more review.

Am I correct in understanding that we will need to recreate the existing data in production after this is deployed?

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
35028761	Triggered	Generic High Entropy Secret	aa87ed7	ecommerce/fixtures.py	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}