Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: implement SHOW_REGISTRATION_LINKS setting #1066

Conversation

CefBoud
Copy link
Contributor

@CefBoud CefBoud commented Oct 2, 2023

Description

This PR implements the newly added SHOW_REGISTRATION_LINKS setting whose purpose is to hide the public registration functionality without disabling the register API.

ALLOW_PUBLIC_ACCOUNT_CREATION is already taken into account in the frontend-app-authn and is expected to be set through the runtime configuration.

This PR introduces the possibility of adding the SHOW_REGISTRATION_LINKS setting to the MFE runtime config so it can be taken into account for hiding the register functionality without disabling the API, thus replicating the legacy LMS flow.

How Has This Been Tested?

The steps to test are as follows:

  1. LMS configuration:
    • Set ENABLE_MFE_CONFIG_API to True in the LMS settings
    • Set SHOW_REGISTRATION_LINKS to False in the MFE_CONFIG dict in the LMS settings
  2. frontend-app-authn configuration:
  3. Launch LMS + frontend-app-authn in Devstack
  4. Head to http://localhost:1999/login. There should be no register tab.

NB: mind the MFE_CONFIG_API_CACHE_TIMEOUT setting if you want to play around with MFE_CONFIG. The result is cached for 5min by default. The runtime config also relies on client-side caching, so better to rely on private browsing if there is a config change.

Screenshots/sandbox (optional):

Include a link to the sandbox for design changes or screenshot for before and after. Remove this section if its not applicable.

Before After
image image

Merge Checklist

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

Post-merge Checklist

  • Deploy the changes to prod after verifying on stage or ask @openedx/vanguards to do it.
  • 🎉 🙌 Celebrate! Thanks for your contribution.

@CefBoud CefBoud requested a review from a team as a code owner October 2, 2023 13:22
@openedx-webhooks openedx-webhooks added the open-source-contribution PR author is not from Axim or 2U label Oct 2, 2023
@openedx-webhooks
Copy link

openedx-webhooks commented Oct 2, 2023

Thanks for the pull request, @CefBoud! 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.

@mphilbrick211 mphilbrick211 added the needs test run Author's first PR to this repository, awaiting test authorization from Axim label Oct 2, 2023
@zainab-amir
Copy link
Contributor

We will be reviewing this in the coming sprint.

@codecov
Copy link

codecov bot commented Oct 4, 2023

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (7f8a270) 87.05% compared to head (3d2850d) 87.08%.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1066      +/-   ##
==========================================
+ Coverage   87.05%   87.08%   +0.02%     
==========================================
  Files         124      124              
  Lines        2271     2276       +5     
  Branches      629      634       +5     
==========================================
+ Hits         1977     1982       +5     
  Misses        285      285              
  Partials        9        9              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@navinkarkera
Copy link

@CefBoud The implementation in legacy or non-mfe UI just hides the registration links but allows users to go the the URL directly.

Here we are completely disabling register page which is already implemented using ALLOW_PUBLIC_ACCOUNT_CREATION setting. We should either configure the UI such that it only hides the register tab but shows it if you access it via the correct url or close this PR if it is not possible.

@CefBoud CefBoud force-pushed the CefBoud/add_show_registration_links_setting branch 2 times, most recently from 494aaa2 to 317a179 Compare October 7, 2023 10:41
@CefBoud
Copy link
Contributor Author

CefBoud commented Oct 7, 2023

@navinkarkera You are absolutely right.
I just pushed a fix to hide the register tab but keep it accessible.

Copy link

@navinkarkera navinkarkera left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@CefBoud Nice work! Left a suggestion about keeping tabs, please have a look.

Comment on lines +120 to 123
: (!isValidTpaHint() && !hideRegistrationLink && (
<Tabs defaultActiveKey={selectedPage} id="controlled-tab" onSelect={handleOnSelect}>
<Tab title={formatMessage(messages['logistration.register'])} eventKey={REGISTER_PAGE} />
<Tab title={formatMessage(messages['logistration.sign.in'])} eventKey={LOGIN_PAGE} />

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
: (!isValidTpaHint() && !hideRegistrationLink && (
<Tabs defaultActiveKey={selectedPage} id="controlled-tab" onSelect={handleOnSelect}>
<Tab title={formatMessage(messages['logistration.register'])} eventKey={REGISTER_PAGE} />
<Tab title={formatMessage(messages['logistration.sign.in'])} eventKey={LOGIN_PAGE} />
: (!isValidTpaHint() && (
<Tabs defaultActiveKey={selectedPage} id="controlled-tab" onSelect={handleOnSelect}>
<Tab title={formatMessage(messages['logistration.sign.in'])} eventKey={LOGIN_PAGE} />
{!hideRegistrationLink || selectedPage === REGISTER_PAGE && (<Tab title={formatMessage(messages['logistration.register'])} eventKey={REGISTER_PAGE} />)}

Instead of adding a new h3 element, can we hide/show register tab based on the flag and url, something like above. This way users have a way to go to sign-in page from register page like they would normally do if both tabs are enabled.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@navinkarkera Thanks for the review.

Well spotted! You put your finger on the dilemma I was facing before opting for the new h3 element. My decision was motivated by the following:

  1. In the majority of cases, only the login page will be accessible, and I tried to replicate the design of the scenario ALLOW_PUBLIC_ACCOUNT_CREATION == false. I find this design cleaner because if we leave a single tab, it remains clickable but also invites the question why is it a tab if there are no other tabs?
  2. I considered the problem of users not having a way to go to login from register and I convinced myself that register in the scenario of SHOW_REGISTRATION_LINKS == false if more of a fallback than the main path. In addition and this is purely subjective, the disappearance of the register tab (if we opt for keeping the tabs) when we make the transition register => login seemed off.

However, your suggestion makes the code cleaner and is easier to reason about. I am happy to go either way.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to replicate the design of the scenario ALLOW_PUBLIC_ACCOUNT_CREATION == false

@CefBoud Ahh, makes sense. I did not notice that before. Thanks for the detailed explanantion.

I agree with your approach so propose to keep the h3 element and leave this thread open to get suggestions from upstream reviewers.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@navinkarkera Ok, great. Thank you for taking the time.
@mubbsharanwar, I am taking the liberty to ping you as an FYI as you were the one who requested the changes.

Comment on lines +130 to +134
{!institutionLogin && !isValidTpaHint() && hideRegistrationLink && (
<h3 className="mb-4.5">
{formatMessage(messages[selectedPage === LOGIN_PAGE ? 'logistration.sign.in' : 'logistration.register'])}
</h3>
)}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If my suggestion above makes sense, we can remove this part.

Comment on lines +114 to +131
it('should render login/register headings when show registration links is disabled', () => {
mergeConfig({
SHOW_REGISTRATION_LINKS: false,
});

let props = { selectedPage: LOGIN_PAGE };
let logistration = mount(reduxWrapper(<IntlLogistration {...props} />));

// verifying sign in heading
expect(logistration.find('#main-content').find('h3').text()).toEqual('Sign in');

// register page is still accessible when SHOW_REGISTRATION_LINKS is false
// but it needs to be accessed directly
props = { selectedPage: REGISTER_PAGE };
logistration = mount(reduxWrapper(<IntlLogistration {...props} />));

// verifying register heading
expect(logistration.find('#main-content').find('h3').text()).toEqual('Register');

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test will also need to be updated if my suggestion makes sense.

Copy link

@navinkarkera navinkarkera left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

  • I tested this: by setting up the config locally.
  • I read through the code
  • I checked for accessibility issues
  • Includes documentation: Cannot find a place where these variables related to MFE_CONFIG are documented.
  • I made sure any change in configuration variables is reflected in the corresponding client's configuration-secure repository.

@CefBoud CefBoud force-pushed the CefBoud/add_show_registration_links_setting branch from 317a179 to c04e7f5 Compare October 9, 2023 09:21
@e0d e0d removed the needs test run Author's first PR to this repository, awaiting test authorization from Axim label Oct 10, 2023
@mphilbrick211
Copy link

Hi @openedx/vanguards! Would someone be able to review/merge this for us? Thanks!

@mphilbrick211
Copy link

Hi @openedx/vanguards! Just checking in on this.

@mphilbrick211
Copy link

Friendly ping on this, @openedx/vanguards :)

@mphilbrick211 mphilbrick211 added the waiting for eng review PR is ready for review. Review and merge it, or suggest changes. label Nov 14, 2023
@zainab-amir
Copy link
Contributor

Apologies for the delay. @mubbsharanwar will be reviewing this change.

@@ -39,6 +39,7 @@ const Logistration = (props) => {
const [key, setKey] = useState('');
const navigate = useNavigate();
const disablePublicAccountCreation = getConfig().ALLOW_PUBLIC_ACCOUNT_CREATION === false;
const hideRegistrationLink = getConfig().SHOW_REGISTRATION_LINKS === false;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add SHOW_REGISTRATION_LINKS flag in src/config/index.js to utilize this flag using getConfig

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mubbsharanwar Done. I'd like to point out that because the default value of this param is true and AFAIK there is no way to specify a boolean as an env variable, I resorted to using an explicit comparison with the string 'false'.

@CefBoud CefBoud force-pushed the CefBoud/add_show_registration_links_setting branch from c04e7f5 to 14cd117 Compare November 19, 2023 13:00
@mubbsharanwar
Copy link
Contributor

@CefBoud Thank you for this contribution really appreciated, Please rebase the branch then I will merge these changes.

@CefBoud CefBoud force-pushed the CefBoud/add_show_registration_links_setting branch from 14cd117 to 9e83f00 Compare November 20, 2023 09:27
@CefBoud
Copy link
Contributor Author

CefBoud commented Nov 20, 2023

@mubbsharanwar My pleasure. Rebased.

@mphilbrick211
Copy link

@mubbsharanwar thank you for your review! Would you mind enabling tests to run again?

@CefBoud CefBoud force-pushed the CefBoud/add_show_registration_links_setting branch from 9e83f00 to 3d2850d Compare November 21, 2023 06:48
@CefBoud
Copy link
Contributor Author

CefBoud commented Nov 21, 2023

@mubbsharanwar Apologies regarding the linting issues. I replaced the ternary and the issue is fixed.

@mubbsharanwar mubbsharanwar merged commit 78722f3 into openedx:master Nov 21, 2023
7 checks passed
@openedx-webhooks
Copy link

@CefBoud 🎉 Your pull request was merged! Please take a moment to answer a two question survey so we can improve your experience in the future.

@itsjeyd itsjeyd removed the waiting for eng review PR is ready for review. Review and merge it, or suggest changes. label Nov 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
open-source-contribution PR author is not from Axim or 2U
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

8 participants