Only display Preview Language Setting (dark_lang) in LMS

[salman2013]

Description

We disable the Studio Preview Language Setting Page, and redirect it to the identical LMS Preview Language Setting page. This is one of the final bits of the legacy Studio frontend. By making it render only in LMS, we unblock the full retirement of the legacy Studio frontend.

Supporting info

Before

There were two views allowing to staff to choose to preview a "dark" language, both of which are completely identical in functionality. The only difference is the header, footer, and styling surrounding them.

1. Studio Context (<CMS_ROOT_URL>/update_lang)

2. LMS Context (<LMS_ROOT_URL>/update_lang)

After

The Studio URL (1) will simply redirect to the LMS URL (2). In other words, the Preview Language Setting page will only render in an LMS context.

This has no impact on end-user functionality. It has only a very minor UX end-user impact (LMS header+footer rather than Studio header+footer). The LMS styling seems to be better, anyway.

Test instructions

• Navigate to <CMS_BASE>/update_lang
• Log in as global staff
• You should be redirected to <LMS_BASE>/update_lang.
• Enter a language code (e.g., es)
• Confirm that both Studio and LMS appear in that language.

Other information

The actual affect of this simple page is to set a UserPreference item with the key dark-lang, allowing staff to see what their Open edX looks like in a language which is not (yet) available to users in general. Assuming that this is a useful feature, we will need to reimplement the page in an MFE eventually. My thought is that the Account Settings page in frontend-app-account is the correct destination for this if and when it is written. If it is not rewritten, we will need to DEPR it.

Ticket: #36277

[openedx-webhooks]

Thanks for the pull request, @salman2013!

This repository is currently maintained by @openedx/wg-maintenance-openedx-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.

🔘 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

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

[salman2013]

@kdmccormick Please take a look at this PR, as you created the original one: #36271. I have now recreated it.

The previously failing tests are no longer applicable due to recent changes. Since the endpoint now redirects, the expected session behavior is no longer established, making the existing tests ineffective.

[kdmccormick]

@salman2013 I am confused--I thought that endpoint would redirect if you call it from CMS, but would still work as before if you call it from the LMS. Does this test pass in both LMS and CMS? If it passes in LMS, then why is it redirecting back into the same path in LMS?

[salman2013]

As per my understanding It redirect on both cases, LMS and CMS
In LMS this redirects to the same host and path (e.g. /update_lang/). Ref:

openedx-platform/openedx/core/djangoapps/dark_lang/views.py

Line 74 in 4a49a95

return redirect(request.path)

In CMS now lambda redirects to {LMS_ROOT_URL}/update_lang/
Ref:

openedx-platform/cms/urls.py

Line 89 in 7eb9c98

path('update_lang/', lambda request: redirect(f'{settings.LMS_ROOT_URL}/update_lang/')),

[kdmccormick]

ah, OK, but that redirect after completing the POST action, right? We still need _post_set_preview_lang and _post_clear_preview_lang to work (at least on the LMS side), otherwise we are not testing that users can set and clear their preview language.

[salman2013]

I tried to write tests but faced failure,
By using LLM i found the logical reason when the old URL used include(...), a POST from the test client to /update_lang/ was handled in-process: the Django test client's request went directly into PreviewLanguageFragmentView.post(), the view called set_user_preference(), wrote to the database, and returned a
302 → /update_lang/ (a same-server redirect). The test client's session was live the whole time.

After the change, that same POST hits the lambda, which immediately returns 302 → http://localhost:18000/update_lang/. The test client sees
a redirect response and stops. It does not follow it, because Django's test client only follows redirects within the same Django application
instance — it has no concept of making a real TCP connection to another port. localhost:18010 (CMS test server) and localhost:18000 (LMS
test server) are treated as different servers even though they share the same process during tests. The result is that the test's POST never
reaches PreviewLanguageFragmentView at all. set_user_preference() is never called, the dark-lang preference row is never written to the
database, and get_user_preference() returns None hence _post_set_preview_lang test always fails.

[kdmccormick]

I could see how that would fail in CMS.

Does it test pass in LMS? We could use @skip_unless_lms

[salman2013]

yes the tests pass in LMS, let me try @skip_unless_lms

[salman2013]

I skipped the failing tests for cms.

[kdmccormick]

Looks great, thanks @salman2013 !

I tested on the sandbox:

• Redirect from CMS
• Setting to a few languages, including
  • a supported language, es (spanish)
  • a "dark" (unsupported) language, eo ("esperanto")
• Resetting back to default when user language is english
• Resetting back to default when user language is spanish