-
Notifications
You must be signed in to change notification settings - Fork 127
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: set username behind flag #465
Conversation
ccc6023
to
e0b060d
Compare
61df27f
to
cf0f69a
Compare
66a0c4c
to
4cc31ca
Compare
@@ -128,6 +128,13 @@ describe('Header', () => { | |||
expect(avatarIcon).toBeVisible(); | |||
}); | |||
|
|||
it.only('user menu should not contain username', async () => { | |||
const newProps = { ...props, ENABLE_HEADER_WITHOUT_USERNAME: true }; |
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.
Why are we sending the environment variable as a prop?
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.
Mistakenly added it here, We are enabling this flag using mergeConfig.
2a34074
to
c5935e5
Compare
@zainab-amir Addressed your comments. |
dd978ec
to
dbda420
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #465 +/- ##
==========================================
+ Coverage 66.96% 68.09% +1.12%
==========================================
Files 25 25
Lines 339 351 +12
Branches 78 85 +7
==========================================
+ Hits 227 239 +12
Misses 110 110
Partials 2 2 ☔ View full report in Codecov by Sentry. |
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.
Minor comments. Thankyou
ef31ead
to
7fa9371
Compare
const dashboardMenuItem = ( | ||
<Dropdown.Item href={`${getConfig().LMS_BASE_URL}/dashboard`}> | ||
{intl.formatMessage(messages.dashboard)} | ||
</Dropdown.Item> | ||
); | ||
|
||
// show avatar instead username if HIDE_USERNAME_FROM_HEADER flag is 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.
// show avatar instead username if HIDE_USERNAME_FROM_HEADER flag is enabled | |
// show avatar instead of username if `HIDE_USERNAME_FROM_HEADER flag` is enabled |
username would be show in header bt enabling ENABLE_HEADER_WITHOUT_USERNAME flag. VAN-1804 fix: address reviewer comments
7fa9371
to
fcaa2b6
Compare
@mubbsharanwar Given this is making a change to the shared Open edX component header, should we seek reviewers/approval in the community Frontend Working Group or other stakeholders from the Open edX community? Otherwise, if these changes are specific to a 2U/edX.org decision, should these changes be made in the |
@adamstankiewicz thank you for sharing the information on the override for frontend-component-header. We will be making these changes to @edx/frontend-component-header-edx (we won't even need to keep this change behind a flag!) |
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.
Overall this looks very cleanly implemented! I left a couple of comments with questions and I'm looking forward to hearing what others think about those.
@@ -49,6 +49,7 @@ Environment Variables | |||
* ``ACCOUNT_PROFILE_URL`` - The URL of the account profile page. | |||
* ``ACCOUNT_SETTINGS_URL`` - The URL of the account settings page. | |||
* ``AUTHN_MINIMAL_HEADER`` - A boolean flag which hides the main menu, user menu, and logged-out | |||
* ``HIDE_USERNAME_FROM_HEADER`` - A boolean flag which hides the username from the header |
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.
General question (hoping to hear what others think): Do we prefer this as HIDE
or as SHOW
? I could be persuaded 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.
Come to think of it, I could even see this being non-boolean: something like NAME_IN_MENU_BUTTON
with the options being username
, fullName
, none
@@ -26,6 +26,7 @@ subscribe(APP_READY, () => { | |||
authenticatedUser: { | |||
userId: '123abc', | |||
username: 'testuser', | |||
name: 'test user', |
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.
Another general question: Would we prefer this as fullName
? With this test data I'm assuming we'd expect both first and last name in here. If that's the case I feel fullName
is more descriptive.
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.
The authenticated data sent in JWT has "name" not "fullName"
|
||
return ( | ||
<Menu transitionClassName="menu-dropdown" transitionTimeout={250}> | ||
<MenuTrigger | ||
tag="button" | ||
aria-label={intl.formatMessage(messages['header.label.account.menu.for'], { username })} | ||
aria-label={intl.formatMessage(messages['header.label.account.menu.using.name.or.username'], { usernameOrName })} |
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.
Another open question: Do we want to use a new message key here?
An alternative solution that comes to mind is
aria-label={intl.formatMessage(messages['header.label.account.menu.using.name.or.username'], { usernameOrName })} | |
aria-label={intl.formatMessage(messages['header.label.account.menu.for'], { username: usernameOrName })} |
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.
name should be added to the authenticatedUser
in the context for the StudioHeader
too
|
||
return ( | ||
<Menu transitionClassName="menu-dropdown" transitionTimeout={250}> | ||
<MenuTrigger | ||
tag="button" | ||
aria-label={intl.formatMessage(messages['header.label.account.menu.for'], { username })} | ||
aria-label={intl.formatMessage(messages['header.label.account.menu.using.name.or.username'], { usernameOrName })} | ||
className="btn btn-outline-primary d-inline-flex align-items-center pl-2 pr-3" | ||
> | ||
<Avatar size="1.5em" src={avatar} alt="" className="mr-2" /> |
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 know this wasn't added in this PR, but StudioHeader uses name/username for the alt test in UserMenu. Does it make sense to do the same here for consistency?
const hideUsername = getConfig().HIDE_USERNAME_FROM_HEADER; | ||
const usernameOrName = hideUsername ? name : username; |
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.
It looks like this has been implemented in a way that assumes the "hide username from menu button in header" is tied to "don't use usernames." It seems to me those are two separate things. I could definitely see someone running an Open edX instance that uses usernames but not wanting to show them in the menu dropdown button.
In this case the difference seems quite minor, but I can imagine scenarios where having "hide username" and "we don't use usernames" coupled could be problematic.
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.
We will be auto-generating username and showing that in alt text doesn't make sense. I can see how HIDE_USERNAME_FROM_HEADER
doesn't provide more context around this.
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.
Maybe we can go with your suggestion of NAME_IN_MENU_BUTTON
. Which tells us whether we want to use username
or fullName
in the header and use the same in screen reader text too.
Thanks for flagging this for product review. The linked "MVP scope doc" which I presume has additional product context to help make a decision is not available. Could this doc please be added to the Open edX product wiki? I created a space where you can copy/paste the doc: https://openedx.atlassian.net/wiki/spaces/OEPM/pages/4060938253/Proposal+-+Set+username+behind+flag+across+MFE+headers |
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.
Aside from the whole product discussion, as I've mentioned below (and elsewhere), I don't think it makes architectural sense for the logic to select between username and name to reside in DesktopHeader
.
Also, given the scope of the proposal, I believe the decision of what to show the user what their identifier is (whether username, full name, email, or blank) should be made in a place closer to the data source (like in edx-platform), and just passed along as a string in the REST API and down props until it gets to the header.
userMenu, | ||
avatar, | ||
name, |
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'll copy-paste from another review on a related PR:
This would make so there's no longer a 1:1 relationship between the DesktopHeader props and what is actually shown. In other words, it's not immediately obvious without looking at the implementation what happens if you provide both username and name.
In other words, unless I'm missing something, DesktopHeader has no reason to distinguish between username
and name
. It should just use a single prop, and the business logic of what to actually put there should be up to the user of the component.
This PR is not needed anymore. For edX we have solved this by npm aliasing the header with edX specific header. |
In the spirit of making registration experience quick and easy (more details on the proposal page in the wiki, we want to be able to remove username from the registration form. This creates the need to remove it everywhere on the UX too. As part of this initiative, we will be removing username from the headers and making the dropdown consistent with edx.org site.
Changes
Added another variation where header is rendered without the username. This variation is kept behind the
HIDE_USERNAME_FROM_HEADER
environment variable. By default, this feature is turned off.Screenshots
Ticket
VAN-1804