feat: Get microfrontend URLs from site configuration - tests

[javiboo]

Description

Since Maple release, Learning Micro-Frontend (MFE) becomes the default courseware experience, but Multisites have not been considered.
The Learning MFE URL cannot be conifgured per site because the value is not being retrieved through the site configuration
by using the site configuration helper, as it is being done in other points of the platform to obtain other values from the settings.
This commit changes this behaviour introducing the retrieval of Learning but also Account, Profile and Authn MFE URLs through the helper.

This change has impact in "Operator" roles, because they can override MFE URLs in every site configuration.

Supporting information

We have an open discussion about this topic:
https://discuss.openedx.org/t/how-to-use-microfrontend-in-a-multitenant-instance/6936/1

Testing instructions

1. Create a Site in LMS administration: http(s)://{{ LMS_BASE }}/admin/sites/site/
2. Create a Site Configuration: http(s)://{{ LMS_BASE }}/admin/site_configuration/siteconfiguration/
3. Provide a Site value for the LEARNING_MICROFRONTEND_URL property
4. Browse the dashboard of the Site you have created at first step and check that the link of the course corresponds with the LEARNING_MICROFRONTEND_URL value

Deadline

May 1, 2022 We have commitments with our customers in next month that cannot address without Multisites and we have done the migration to Maple release and now go back would be painful.

Other information

This change would be complemented by extending the initialization handler for config runtime in the microfrontends platform to get the site configuration values through a REST API with a new handler, as mentioned in the discussion by dcoa

[openedx-webhooks]

Thanks for the pull request, @javiboo! I've created OSPR-6579 to keep track of it in JIRA, where we prioritize reviews. Please note that it may take us up to several weeks or months to complete a review and merge your PR.

Feel free to add as much of the following information to the ticket as you can:

• supporting documentation
• Open edX discussion forum threads
• timeline information ("this must be merged by XX date", and why that is)
• partner information ("this is a course on edx.org")
• any other information that can help Product understand the context for the PR

All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here.

Please let us know once your PR is ready for our review and all tests are green.

[natabene]

@javiboo Thank you for the contribution! Once you have signed the Contributor Agreement and it has been processed, you will receive a confirmation via email from our Legal team. We then will be able to review this and all your future code contributions.

[javiboo]

I have already signed the agreement so I will wait for your Legal team Thanks. El mié, 6 abr 2022 a las 16:14, Natalia Berdnikov ***@***.***>) escribió:

…

@javiboo <https://github.com/javiboo> Thank you for the contribution! Once you have signed the Contributor Agreement and it has been processed, you will receive a confirmation via email from our Legal team. We then will be able to review this and all your future code contributions. — Reply to this email directly, view it on GitHub <#30186 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABEV7S5V5KVVF3M4O4K3LGDVDWL5DANCNFSM5SU5EX2Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- *Javier Boó Gustems* ***@***.***

[natabene]

@javiboo Thank you, your CLA check will clear soon. I will let you know once it happens.

[openedx-webhooks]

Hello @javiboo: We are unable to continue with review of your submission at this time. Please see the associated JIRA ticket for more explanation.

[natabene]

@javiboo Apologies for a delay, we are good with the CLA check now.

[nsprenkle]

Proposed refactor: should probably use a urljoin to do this more robustly (see example)

[nsprenkle]

Also, open question, does this also need to be merged to master or just the named release?

[nsprenkle]

Want to also ping @davidjoy to make sure we're not missing anything from an architectural/config standpoint.

FYI: @muselesscreator and @leangseu-edx

[davidjoy]

I don't have a lot of input here w/r/t how this config works. @openedx/tcril-engineering, are you able to sanity check whether this is the direction we want to go, re: MFE config? I feel like you all were able to dig into this more fully in the recent MFE config API PRs, or could point us at a subject matter expert who could weigh in.

[kdmccormick]

Thanks for the ping @davidjoy .

As I understand it, this PR would allow the backend Django settings that specify MFE URLs to be overriden via site_configuration, so it's orthogonal to the MFE Config API. (although, for what it's worth, the MFE Config API also currently supports overriding MFE config values via site_configuration).

I will admit that it does pain me to see site_configuration still in use, because it's another layer on top of our already-complex configuration stack, and it's totally opt-in. That is, features are not aware of site_configuration unless the feature developer particularly goes out of their way to make their feature site_configuration-aware. I would love to see an alternative multi-site config feature that overrides the Django settings directly. I think @felipemontoya says that eduNEXT uses an alternative like that?

However, all that said, we (the community) have not endorsed any alternative yet, and site_configuration is not technically deprecated yet. So I am not against this PR merging.

[felipemontoya]

I would love to see an alternative multi-site config feature that overrides the Django settings directly

We have been using a plugin called eox-tenant to do exactly that. This plugin is currently proposed as the alternative once site_configurations is completely deprecated.

features are not aware of site_configuration unless the feature developer particularly goes out of their way to make their feature site_configuration-aware

Spot on. This was our main motivation for writing that plugin. I wrote many PRs such as this here and eventually started working on something that would let us run multi-tenancy without depending on feature developers to be in the loop of the site_config feature.

[arbrandes]

I'll second @kdmccormick's opinion here. We don't like site_configuration, but until we deprecate it officially it's what we have, and if the PR itself is sound... I don't have any objections.

For starters, @javiboo, looks like we have a few failing checks. Are these due to the PR?

[bradenmacdonald]

@javiboo Thanks again for this contribution. Are you planning to continue with this PR? (Get the CI checks passing)

[mphilbrick211]

Hi @javiboo - please let us know if you plan to pursue this PR as we may need to close it due to inactivity. Thank you!

[mphilbrick211]

Hi @javiboo - I am closing this PR due to inactivity, though it can be reopened if needed in the future.

[openedx-webhooks]

@javiboo Even though your pull request wasn’t merged, please take a moment to answer a two question survey so we can improve your experience in the future.