-
Notifications
You must be signed in to change notification settings - Fork 155
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
feat: implement SHOW_REGISTRATION_LINKS setting #1066
Conversation
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:
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. |
We will be reviewing this in the coming sprint. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
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. |
@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 |
494aaa2
to
317a179
Compare
@navinkarkera You are absolutely right. |
There was a problem hiding this 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.
: (!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} /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
: (!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.
There was a problem hiding this comment.
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:
- In the majority of cases, only the
login
page will be accessible, and I tried to replicate the design of the scenarioALLOW_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? - I considered the problem of users not having a way to go to
login
fromregister
and I convinced myself thatregister
in the scenario ofSHOW_REGISTRATION_LINKS == false
if more of a fallback than the main path. In addition and this is purely subjective, the disappearance of theregister
tab (if we opt for keeping the tabs) when we make the transitionregister => login
seemed off.
However, your suggestion makes the code cleaner and is easier to reason about. I am happy to go either way.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
{!institutionLogin && !isValidTpaHint() && hideRegistrationLink && ( | ||
<h3 className="mb-4.5"> | ||
{formatMessage(messages[selectedPage === LOGIN_PAGE ? 'logistration.sign.in' : 'logistration.register'])} | ||
</h3> | ||
)} |
There was a problem hiding this comment.
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.
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'); |
There was a problem hiding this comment.
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.
There was a problem hiding this 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'sconfiguration-secure
repository.
317a179
to
c04e7f5
Compare
Hi @openedx/vanguards! Would someone be able to review/merge this for us? Thanks! |
Hi @openedx/vanguards! Just checking in on this. |
Friendly ping on this, @openedx/vanguards :) |
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; |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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'
.
c04e7f5
to
14cd117
Compare
@CefBoud Thank you for this contribution really appreciated, Please rebase the branch then I will merge these changes. |
14cd117
to
9e83f00
Compare
@mubbsharanwar My pleasure. Rebased. |
@mubbsharanwar thank you for your review! Would you mind enabling tests to run again? |
9e83f00
to
3d2850d
Compare
@mubbsharanwar Apologies regarding the linting issues. I replaced the ternary and the issue is fixed. |
@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. |
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 thefrontend-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:
ENABLE_MFE_CONFIG_API
to True in the LMS settingsSHOW_REGISTRATION_LINKS
to False in theMFE_CONFIG
dict in the LMS settingsMFE_CONFIG_API_URL
to 'http://localhost:18000/api/mfe_config/v1' in.env.development
to enable runtime confregister
tab.NB: mind the
MFE_CONFIG_API_CACHE_TIMEOUT
setting if you want to play around withMFE_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.
Merge Checklist
Post-merge Checklist