Repository navigation
Enable the Contact Us support launcher on the mitxonline MFEs - #6549
Conversation
Appzi reaches every mitxonline MFE through a single appzi_url on OpenEdxVars that mfe_params fans out to each MFE's build. The Contact us launcher replaces it, so it is wired the same way: one contact_us_support_api_url field, one CONTACT_US_SUPPORT_API_URL build var, and lehrer's Footer.jsx picks it up. rc gets it alongside production, so the launcher can be exercised against the rc learn-ai backend before it reaches learners. Appzi stays production-only and untouched here; removing it is a later step. The endpoint is its own field rather than derived from mit_learn_api_url the way FEEDBACK_SUBMIT_URL is. That URL is also set on mitxonline CI, so deriving it would have switched CI on against a learn-ai deployment nobody has pointed a support bot at. The test pins the enabled set to rc and production and fails if a third environment picks it up by accident. Refs hq#13991
Review follow-ups: - Move the "why a field, not derived from mit_learn_api_url" rationale onto the field in pipeline.py, where someone refactoring it will see it. It was only in the test module docstring. - Key the params by MFE so a coverage failure names the MFE that is missing. - Drop test_appzi_is_still_production_only. It pinned config this change does not touch and would have failed when Appzi is removed, which is the goal. Refs hq#13991
![agent-optibot[bot]](https://avatars.githubusercontent.com/in/934808?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary
Enables the contact-us support launcher for every MFE in RC and production environments, using environment-specific Learn AI support endpoints. Other environments remain disabled, preventing accidental enablement based on shared API configuration.
Key Changes
- Adds an explicit per-environment contact-us support API URL configuration.
- Propagates the support endpoint into all generated MFE parameters.
- Enables RC and production with their corresponding Learn AI support-agent endpoints.
- Verifies enabled environments, disabled environments, endpoint selection, and complete MFE coverage.
All Relevant File Changes (click to expand)
src/ol_concourse/pipelines/open_edx/mfe/pipeline.py: Adds and exports the explicit contact-us support API URL parameter.src/ol_concourse/pipelines/open_edx/mfe/values.py: Configures RC and production support-agent endpoints.tests/ol_concourse/test_open_edx_mfe_contact_us.py: Tests environment-specific enablement and endpoint coverage across MFEs.
💬 Feedback & Commands
Share feedback on my comments with 👍 👎 — I'll stop raising issues you push back on. Think I missed something? Adjust my sensitivity →
5 things I can do →
#optibot review— I'll re-review your latest changes (incremental)#optibot full review— I'll re-review the entire PR from scratch#optibot fix— I'll apply my suggested fixes to your code#optibot compliance— I'll run a compliance check on your changes#optibot release notes— I'll write up release notes for your production release
💡 Tip: I can apply my own suggestions directly to your branch — stop copy-pasting and stay in flow with Auto Fixer.
- 🔄 re-review this PR
There was a problem hiding this comment.
Summary
Enables the Contact Us support launcher for all MFEs in selected environments, replacing Appzi with environment-specific support-agent backends. RC and production receive their respective endpoints, while other environments remain disabled to prevent unintended activation.
Key Changes
- Adds a per-environment Contact Us support API configuration.
- Exposes the configured support endpoint to every MFE’s runtime parameters.
- Enables RC and production support-agent backends while keeping other environments disabled.
- Verifies endpoint targeting and coverage across all MFEs.
All Relevant File Changes (click to expand)
- src/ol_concourse/pipelines/open_edx/mfe/pipeline.py: Adds Contact Us support endpoint configuration and MFE parameter output.
- src/ol_concourse/pipelines/open_edx/mfe/values.py: Configures RC and production support-agent endpoints.
- tests/ol_concourse/test_open_edx_mfe_contact_us.py: Validates environment targeting and endpoint coverage across MFEs.
💬 Feedback & Commands
Share feedback on my comments with 👍 👎 — I'll stop raising issues you push back on. Think I missed something? Adjust my sensitivity →
5 things I can do →
#optibot review— I'll re-review your latest changes (incremental)#optibot full review— I'll re-review the entire PR from scratch#optibot fix— I'll apply my suggested fixes to your code#optibot compliance— I'll run a compliance check on your changes#optibot release notes— I'll write up release notes for your production release
💡 Tip: I can apply my own suggestions directly to your branch — stop copy-pasting and stay in flow with Auto Fixer.
There was a problem hiding this comment.
🔵 Needs a closer look
Production rollout requires coordination with the companion footer change, RC end-to-end validation, and learning-MFE-first deployment.
No open issues 🎉
What changed in this PR
Adds explicit, per-environment configuration for the Contact Us launcher on mitxonline MFEs, supporting RC validation against its own backend before learner-facing rollout.
Changes:
- Exposes the optional
CONTACT_US_SUPPORT_API_URLbuild variable. - Configures separate endpoints for mitxonline RC and production, leaving other environments disabled and Appzi unchanged.
- Adds parameterized tests for endpoint selection and propagation across MFEs.
| File | Description |
|---|---|
| tests/ol_concourse/test_open_edx_mfe_contact_us.py | Tests environment-specific endpoints and MFE coverage. |
| src/ol_concourse/pipelines/open_edx/mfe/values.py | Sets RC and production support endpoints. |
| src/ol_concourse/pipelines/open_edx/mfe/pipeline.py | Adds the optional configuration field and build variable. |
Review effort: Balanced
|
Both findings check out as false against the code. KeyError for Vacuous pass when The two claims also contradict each other: an environment that raises
|
|
Understood, thanks for verifying against the code and test run. You can disregard those findings. |
Also trims the comments on the pipeline change.
…ction Production Zendesk is not configured yet -- AI_ZENDESK_API_URL is empty, the three custom-field ids are "0", and no OAuth credentials exist outside QA. A production build would ship a launcher that holds a full conversation and then fails at send. The MFE gate is build-time, so there is no runtime switch to pull it back: the fix would be another build and another CI->QA->Prod promotion. Shipping rc-only costs nothing, since rc is where the verification pass happens anyway, and leaves one line to restore once #6548 lands. Refs hq#14033
What are the relevant tickets?
Refs mitodl/hq#14033, under mitodl/hq#13712
Description (What does it do?)
Appzi is the feedback widget on the mitxonline MFEs today, and it runs on
production only. The Contact Us launcher replaces it, but it needs time on rc
against the rc learn-ai backend before learners see it. So this turns it on for
mitxonline rc and leaves every other environment dark, production included.
OpenEdxVars.contact_us_support_api_url, surfaced to the MFE build asCONTACT_US_SUPPORT_API_URLmitxonline-qa(rc) onlyThe footer change that consumes the variable is mitodl/lehrer#346.
Production is deliberately left out, and an earlier push of this branch had
it set. Production Zendesk is not configured yet — #6548
sets the keys on QA only, so on production
AI_ZENDESK_API_URLis empty, thethree custom-field ids are
"0", and there are no OAuth credentials. Aproduction build would ship a launcher that holds a full conversation and then
fails at
send. Because the gate is build-time there is no runtime switch topull it back — the fix would be another build and another CI→QA→Prod promotion.
Restoring it is one line once #6548 lands.
Implementation details
The endpoint is an explicit per-environment field rather than something derived
from
mit_learn_api_urlthe wayFEEDBACK_SUBMIT_URLis.mit_learn_api_urlis also set on
mitxonline-ci, so deriving would have switched CI on as a sideeffect.
mfe_paramsdrops keys whose value isNone, so the 11 environments withoutthe field pass no flag to the build at all.
The variable reaches all seven mitxonline MFEs — admin-console, communications,
authoring, discussions, gradebook, learning, ora-grading — because lehrer's
Footer.jsxis copied into every legacy MFE build.How can this be tested?
uv run pytest tests/ol_concourse/ -q— 557 passed, 11 skipped.The new
tests/ol_concourse/test_open_edx_mfe_contact_us.pywalks all 12environments in
values.pythroughmfe_paramsand asserts the endpointmatches an explicit enabled list, so a new environment that sets
mit_learn_api_urldoes not pick the launcher up by accident.Nothing is deployed. End-to-end confirmation needs the lehrer change merged and
the MFEs rebuilt.
Additional Context
Two gaps this deliberately leaves open:
GitHub issue, so there is no ordering between MFEs within an environment. The
six non-learning MFEs load the launcher bundle out of the learning MFE's
deploy, so between "gradebook promoted" and "learning promoted" the bundle
404s and the launcher is absent. Promote learning first. The lehrer side logs
the failure rather than swallowing it.
edxapp:appzi_urlfor thenon-MFE LMS pages. Reaching parity there needs a mitxonline-theme change to
lms/templates/footer.html. LMS only — Studio has no Appzi block andcms_interpolated_confighas noAPPZI_URL, so covering Studio would be newsurface rather than parity.
Separately, the OEP-65 Site Project build path (
site_pipeline.py) passes nobuild env vars, so any mitxonline MFE cut over to it would lose the launcher.