-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Adding check to show/hide Avatar form based on whether the user is a … #135743
Adding check to show/hide Avatar form based on whether the user is a … #135743
Conversation
…cloud user or not
@elasticmachine merge upstream |
…f the AuthorizedUser is a cloud user
Based on my initial wireframes (which included cloud flows for user profiles), the hope was that we would offer the following options for cloud users consistently across both the cloud portal and Kibana user menus:
The hope was that Additionally, the For the sake of comparison, we would offer non-cloud users the following options in the Kibana user menu: |
@MichaelMarcialis I removed the 'Preferences' item for cloud and kept the non-cloud as 'Profile' to match the cloud 'Profile' option for a more unified look since we don't have cloud profile editing yet (unless it's ready!) What do you think? |
Pinging @elastic/kibana-security (Team:Security) |
Thanks, @kc13greiner! I have a couple of questions/comments:
|
Exactly that!
I will have to check with @azasypkin since the Cloud Profile menu item is in the Cloud directory (Im not sure what the protocol is for changing other teams files yet.)
Would it be alright if I handle these in a separate PR? |
@elasticmachine merge upstream |
@MichaelMarcialis sorry for the confusion, we referred to the |
@kc13greiner: Certainly. Separate PR would be great!
@azasypkin: Regarding the suggestion to change the text of |
Got it, thanks. If we're not concerned about the |
const profileMenuItem: EuiContextMenuPanelItemDescriptor = { | ||
name: ( | ||
<FormattedMessage | ||
id="xpack.security.navControlComponent.editProfileLinkText" | ||
defaultMessage="{profileOverridden, select, true{Preferences} other{Profile}}" | ||
values={{ profileOverridden: hasCustomProfileLinks }} | ||
defaultMessage="Edit Profile" |
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.
nit: I think you also need to update text here
defaultMessage: 'Profile', |
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.
Resolved in latest commit!
@@ -24061,7 +24061,7 @@ | |||
"xpack.security.management.users.usersTitle": "Utilisateurs", | |||
"xpack.security.management.usersTitle": "Utilisateurs", | |||
"xpack.security.navControlComponent.accountMenuAriaLabel": "Menu Compte", | |||
"xpack.security.navControlComponent.editProfileLinkText": "{profileOverridden, select, true{Préférences} other{Profil}}", | |||
"xpack.security.navControlComponent.editProfileLinkText": "Profil", |
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.
nit: if you happened to update translation files manually then it'd make sense to revert these changes and run node scripts/i18n_check.js --fix
to remove outdated translations instead. Updated translations will be eventually provided by our translators team.
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 translation files have been changed back in the latest commit and re-ran the script
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.
Which looks like it just removed the line entirely, is that correct?
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.
Yep, that's correct!
…ofile link and unit tests
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.
Thanks for putting this together, @kc13greiner. The non-cloud user menu looks good. However, the cloud user menu appears to still show both profile links (first one leads to cloud profile page, second leads to deployment profile page). Can we remove the link to the deployment profile page for cloud users?
…if there is no custom Edit Profile link passed in by another plugin
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.
Thanks for making that change, @kc13greiner. LGTM!
const isAnonymous = currentUser.value ? isUserAnonymous(currentUser.value) : false; | ||
const hasCustomProfileLinks = userMenuLinks.some(({ setAsProfile }) => setAsProfile === true); | ||
|
||
if (!isAnonymous && !hasCustomProfileLinks) { |
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.
issue: while testing this change I discovered that we rely on the user's roles (specifically superuser
role) to determine whether we should show Cloud specific links or not (added in #97870). If we keep this Cloud plugin logic as is, after this PR non-Cloud managed superusers won't be able to edit their profiles in Kibana (we'll be rendering a single Edit profile
link leading to Cloud UI instead of Profile
and Preferences
links we had previously).
@legrego do I understand correctly that we can now switch this code to rely on elastic_cloud_user
user property instead or is there still a legitimate reason for non-Cloud managed superusers to see Cloud specific links?
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.
@legrego do I understand correctly that we can now switch this code to rely on
elastic_cloud_user
user property instead or is there still a legitimate reason for non-Cloud managed superusers to see Cloud specific links?
That's correct, we should switch this code to rely on elastic_cloud_user
instead of the role check. The superuser
check was a hard-coded workaround because we didn't have a way to reliably determine which users were cloud users back then.
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.
Great, thanks for confirming, Larry.
…d related unit tests
💚 Build SucceededMetrics [docs]Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: |
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.
LGTM, great job!
Summary
Removing the UI for Cloud Users to update their avatar (the backend already prohibited Profile updates)
Cloud User:
Non-cloud User:
@MichaelMarcialis I would like to include the changes to the Right Side Nav menu (last point described here.
What are your thoughts?
Resolves #132645