openedx
feat: make ACCOUNT_MICROFRONTEND_URL site aware.
Description
This PR makes the Account MFE base URL site‑aware. All reads of settings.ACCOUNT_MICROFRONTEND_URL are replaced with:
configuration_helpers.get_value('ACCOUNT_MICROFRONTEND_URL', settings.ACCOUNT_MICROFRONTEND_URL)
This lets Operators override the Account MFE host per Site Configuration (multi‑tenant / stage) without code changes or deploy‑time env tweaks. If no override is present, behavior falls back to the Django setting. 
Impacted areas
- Student dashboard Redirects and inlined links now resolve the Account URL via Site Configuration.
- Third‑party auth (TPA) API The redirect_url used post‑auth/linking flows now pulls from Site Configuration.
- ID Verification (IDV) flows
- Management command send_verification_expiry_email: builds account_base_url from Site Configuration.
- verify_student.services.get_verify_location: Account base resolved via Site Configuration.
- verify_student.views.results_callback: reverify_url uses the config‑derived base.
- Header / user dropdown templates “Account” links in Mako templates read the Account base via configuration_helpers.get_value(...).
- Legacy account URLs & cookies
- openedx.core.djangoapps.user_api.legacy_urls: legacy /account(/settings) redirects point at the config‑derived Account MFE.
- openedx.core.djangoapps.user_authn.cookies: header_urls['account_settings'] uses the config value.
- Email & UI helpers
- Bulk email context: account_settings_url now site‑aware; platform_name read via Site Configuration.
- Financial assistance view context: account_settings_url site‑aware; platform_name via Site Configuration.
- Notifications email utils: account_base_url built from Site Configuration for link construction.
- Password policy enforcement
- Non‑compliance banner/link uses the config‑derived Account URL.
Secondary improvement
- Platform name configurability In the bulk email and financial assistance contexts, PLATFORM_NAME is fetched via configuration_helpers.get_value('PLATFORM_NAME', settings.PLATFORM_NAME) to allow per‑site branding.
Supporting information
- No migrations; no operator action required for default deployments.
- Changes are read‑only lookups and string concatenations; no DB schema or data changes.
Testing instructions
Manual validation
- Set a Site Configuration override for ACCOUNT_MICROFRONTEND_URL (e.g., https://account.override.local).
- Navigation links: Log in and open the user dropdown; “Account” should point to the override host.
- Legacy redirects: Hit /account and /account/settings in LMS; you should be redirected to the override host.
- TPA flows: Start a provider connection and confirm the post‑auth redirect_url lands on the override Account MFE.
- IDV: Trigger a failure/denial path in IDV and confirm the “Reverify” link uses the override base; inspect get_verify_location(...) output if testing in a shell.
- Emails/contexts:
- Render a bulk‑email context and verify account_settings_url uses the override; platform_name respects Site Configuration.
- Render a notifications email template context and confirm account_base_url uses the override.
- Password policy: Force a password policy non‑compliant state and verify the banner’s “Account Settings” link points to the override.
Automated tests
# from repo root
pytest -q \
common/djangoapps/third_party_auth/api/tests/test_views.py \
lms/djangoapps/bulk_email/tests/test_tasks.py \
lms/djangoapps/courseware/tests/test_views.py \
lms/djangoapps/verify_student/management/commands/tests/test_send_verification_expiry_email.py \
lms/djangoapps/verify_student/tests/test_services.py \
lms/djangoapps/verify_student/tests/test_views.py \
openedx/core/djangoapps/notifications/email/tests/test_utils.py \
openedx/core/djangoapps/password_policy/tests/test_compliance.py \
openedx/core/djangoapps/user_authn/tests/test_cookies.py
Other information
- Risk: Low.
- Dependencies: None.
- Security/Privacy: No new PII exposure; URLs and encrypted parameters are unchanged beyond host selection.
- Performance: Negligible. Lookups either happen inline or once per import (depending on the module).
- Operator note: For multi‑site instances, ensure each Site sets a correct ACCOUNT_MICROFRONTEND_URL. If omitted, defaults apply.
Thanks for the pull request, @anfbermudezme!
This repository is currently maintained by @openedx/wg-maintenance-edx-platform.
Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.
:radio_button: Get product approval
If you haven't already, check this list to see if your contribution needs to go through the product review process.
- If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
- This process (including the steps you'll need to take) is documented here.
- If it doesn't, simply proceed with the next step.
:radio_button: Provide context
To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:
- Dependencies
This PR must be merged before / after / at the same time as ...
- Blockers
This PR is waiting for OEP-1234 to be accepted.
- Timeline information
This PR must be merged by XX date because ...
- Partner information
This is for a course on edx.org.
- Supporting documentation
- Relevant Open edX discussion forum threads
:radio_button: Get a green build
If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.
Where can I find more information?
If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:
When can I expect my changes to be merged?
Our goal is to get community contributions seen and reviewed as efficiently as possible.
However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:
- The size and impact of the changes that it introduces
- The need for product review
- Maintenance status of the parent repository
:bulb: As a result it may take up to several weeks or months to complete a review and merge your PR.
@anfbermudezme hi there! It looks like there's a failing check here - would you mind taking a look?
