fix: show full country list when LMS sends no country allow-list

[RomkaSk]

Description

On the learner profile page the Country selector renders with a single empty placeholder option - no countries can be selected.

This happens on any deployment that keeps the platform default REGISTRATION_EXTRA_FIELDS['country'] = 'hidden' (edx-platform: openedx/envs/common.py:1679).

Steps to reproduce

1. Leave REGISTRATION_EXTRA_FIELDS['country'] at its default 'hidden' (no Site Configuration override).
2. Log in and open /profile/u/<username>.
3. Click Add country (or the edit icon on the Country block).

Expected: the localized list of countries, as on the Account Settings page.
Actual: the <select id="country"> contains only the empty placeholder — 1 option, 0 countries.

Account	Profile

Root cause

The profile builds its list of selectable countries from the registration form description, not from a country/locale source:

Step	Location	What happens
1	src/profile/data/sagas.js:43-63	fetched alongside account/certificates/preferences on profile load
2	src/profile/data/services.js:158	getCountryList() → GET {LMS_BASE_URL}/user_api/v1/account/registration/
3	src/profile/data/services.js:152	extractCountryList() takes fields[name == 'country'].options, maps them to codes; returns [] on any miss
4	src/profile/data/actions.js:21 → src/profile/data/reducers.js:66	stored in state.profilePage.countriesCodesList
5	src/profile/data/selectors.js:93-103	sortedCountriesSelector filters the full localized list by those codes

The registration endpoint only includes a country field when the registration form is configured to show it. With the default 'hidden', countriesCodesList arrives as [] and the filter is still applied unconditionally:

return countryList.filter(({ code }) => code === userCountry
  || countriesCodesList.find(x => x === code));

Every entry is removed. Only the learner's already-committed country survives, so an account with no country set is left with nothing to choose from.

[] also arrives when the request fails (services.js:164 logs and returns []), so a transient error produces the same dead dropdown.

Regression

Introduced by #1185 (29edfa9, feat: added restricted country functionality), which replaced

sortedCountriesSelector = createSelector(localeSelector,
  locale => getCountryList(locale));

with the allow-list filter. The intent was to hide embargoed countries, but the registration form was used as a proxy for "not embargoed" — which only holds on sites where country is part of signup.

Why Account Settings is not affected

frontend-app-account uses the same endpoint and the same extractCountryList() (src/account-settings/data/service.js:191-202), so its countriesCodesList is empty too. It renders correctly because it guards the empty case (AccountSettingsPage.jsx#L167-L175):

removeDisabledCountries = (countryList) => {
  const { countriesCodesList, committedValues } = this.props;
  const committedCountry = committedValues?.country;

  if (!countriesCodesList.length) {
    return countryList;
  }
  return countryList.filter(({ value }) => value === committedCountry || countriesCodesList.find(x => x === value));
};

The per-option guard is present in both MFEs (length > 0); only the list-level guard is missing in profile.

Fix

Port the account MFE's guard into sortedCountriesSelector — treat an empty list as "the LMS does not restrict the choice":

  // src/profile/data/selectors.js
+ if (countriesCodesList.length === 0) {
+   return countryList;
+ }
  return countryList.filter(({ code }) => code === userCountry
    || countriesCodesList.find(x => x === code));

Country.jsx:45 isDisabledCountry() already short-circuits on countriesCodesList.length > 0, so no other change is needed. Where the LMS does send an allow-list, behaviour is unchanged.

This does not weaken the restriction: embargoed countries are rejected server-side on write, independently of the registration form — edx-platform: openedx/core/djangoapps/user_api/accounts/api.py:162-169 returns a country field error for GlobalRestrictedCountry.is_country_restricted(...). The frontend filter is a UX affordance, not an access control.

One trade-off worth stating: on a site where embargo is enabled and country is hidden in registration, the profile will now offer an embargoed country and the learner will get the server-side field error on save. That is worse than not offering it, but strictly better than today's "no options at all", and it matches what Account Settings already does.

How Has This Been Tested?

• Reproduced on a Tutor dev stack (Verawood) with the stock REGISTRATION_EXTRA_FIELDS: the country <select> had 1 option. With country present in the registration response the same build showed 251 options, confirming the allow-list filter as the cause.
• Added src/profile/data/selectors.test.js with three cases for sortedCountriesSelector: empty countriesCodesList returns the full list; a non-empty list filters to exactly those codes; the country already saved on the account is kept even if it is not in the list. The first case fails on master without this change and passes with it.
• npm run lint clean, npm run test green on Node 24: 14 suites, 85 tests, 5 snapshots. The existing mock stores carry a non-empty countriesCodesList, so their snapshots are unchanged.
• Test in internal ticket

Merge Checklist

• If your update includes visual changes, have they been reviewed by a designer? Send them a link to the Sandbox, if applicable. — N/A, no visual changes.
• Is there adequate test coverage for your changes?

Post-merge Checklist

• Deploy the changes to prod after verifying on stage or ask @jacobo-dominguez-wgu to do it.
• 🎉 🙌 Celebrate! Thanks for your contribution.

[openedx-webhooks]

Thanks for the pull request, @RomkaSk!

This repository is currently maintained by @jacobo-dominguez-wgu.

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.

🔘 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.

🔘 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

🔘 Submit a signed contributor agreement (CLA)

⚠️ We ask all contributors to the Open edX project to submit a signed contributor agreement or indicate their institutional affiliation.
Please see the CONTRIBUTING file for more information.

If you've signed an agreement in the past, you may need to re-sign.
See The New Home of the Open edX Codebase for details.

Once you've signed the CLA, please allow 1 business day for it to be processed.
After this time, you can re-run the CLA check by adding a comment below that you have signed it.
If the CLA check continues to fail, you can tag the @openedx/cla-problems team in a comment for further assistance.

🔘 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.

Details

---

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:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

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

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

[RomkaSk]

#1320

[RomkaSk]

Verawood backport #1402

[mphilbrick211]

Hi @RomkaSk! Welcome, and thank you for this contribution! In order for your CLA check to turn green, you'll need to submit a CLA form. If you are contributing as an individual, please fill out the individual CLA form here.

If you are contributing on behalf of an organization, please have your manager reach out to oscm@axim.org so you may be added to your org's existing entity agreement.

Please let me know if you have any questions. Thanks!