-
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
Update text and icons to align with Cloud #86394
Update text and icons to align with Cloud #86394
Conversation
@elasticmachine merge upstream |
merge conflict between base and head |
ACK: reviewing... |
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 approach looks good to me, but left a few questions and suggestions.
x-pack/plugins/security/public/account_management/account_management_page.tsx
Outdated
Show resolved
Hide resolved
x-pack/plugins/security/public/account_management/account_management_page.test.tsx
Outdated
Show resolved
Hide resolved
x-pack/plugins/security/public/account_management/account_management_page.test.tsx
Outdated
Show resolved
Hide resolved
x-pack/plugins/security/public/nav_control/nav_control_component.tsx
Outdated
Show resolved
Hide resolved
@@ -122,37 +146,38 @@ export class SecurityNavControl extends Component<Props, State> { | |||
const isAnonymousUser = authenticatedUser?.authentication_provider.type === 'anonymous'; | |||
const items: EuiContextMenuPanelItemDescriptor[] = []; | |||
|
|||
if (userMenuLinks.length) { |
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.
question: I see we moved profile link to the bottom now, do we really want to always display Profile
link after any custom user links? I thought it should be the first by default and pushed down by the custom links only if their order
is lower (assuming we set some default order
for default profile link) or what is the plan?
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.
That's a great observation. The most immediate need is alignment with Cloud which means placing their link atop the list and the location of 'Preferences' (after custom links) likewise aligns neatly with their current order.
This is an admittedly simplistic approach, to start - yet it meets the objective - and I would like to see further capabilities such as an order added, subsequently. I personally don't feel comfortable adding that logic, so would you be ok with tracking this separately and handling it post-merge/as the need arises?
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.
Oh wait! I see that the cloud links are defining an order
, but its only being used to sort within custom 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.
With this latest round of updates, I decided to go with simply adding the default profile link in either the first (if no other custom links are set as profile) or last position. The last position being coupled with changing the label to Preferences and changing the icon.
We could get fancier here and so something like set an order value on the default profile link, but I'm not sure if/when we'd need that, thus the simpler approach.
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 could get fancier here and so something like set an order value on the default profile link, but I'm not sure if/when we'd need that, thus the simpler approach.
Agree, makes sense to me 👍
@@ -66,6 +69,27 @@ export class SecurityNavControl extends Component<Props, State> { | |||
componentDidMount() { | |||
this.subscription = this.props.userMenuLinks$.subscribe(async (userMenuLinks) => { | |||
this.setState({ userMenuLinks }); | |||
|
|||
if (userMenuLinks.length) { |
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.
question: do we really need to alter state here? Can't we just check if we have a link with setAsProfile
right before we render default profile link in render
? The perf impact seems to be negligible. Something like this:
if (!isAnonymousUser) {
const hasCustomProfileLinks = userMenuLinks.some(({ setAsProfile }) => setAsProfile === true);
const profileMenuItem = {
name: (
<FormattedMessage
id="xpack.security.navControlComponent.editProfileLinkText"
defaultMessage="{profileOverridden, select, true{Preferences} other{Profile}}"
values={{ profileOverridden: hasCustomProfileLinks }}
/>
),
.....
Regarding multiple links with setAsProfile
, I believe we just should throw error (optionally with detailed explanation that link with labelA
is already used as a profile link) in addUserMenuLinks
in nav_control_service.tsx
right at the moment when something wants to add a link with setAsProfile
when we already have one (the service tracks all links so it should be easy to figure out). People tend to ignore console warnings anyway 🙂
Ideally I'd rather expose dedicated methods to manage (hide/rename) built-in links like Profile and Logout, but I agree that it doesn't make sense to generalize this right now since everything is still in flux, so 👍 to the setAsProfile
approach.
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've removed the state stuff and am now throwing errors for two situations:
- a custom profile link is already set (the name and href for the existing custom profile link are displayed)
- there is no existing custom profile link but the plugin is passing in more than one (the total number passed is displayed).
@elasticmachine merge upstream |
@elasticmachine merge upstream |
merge conflict between base and head |
@elasticmachine merge upstream |
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.
Looks great! Just few minor nits and questions before we 🚀 .
It seems CI is failing for your PR because of a new eslint rule that was added in the upstream recently, you should be able to automatically fix this with:
$ node scripts/eslint.js --fix x-pack/plugins/security/public/account_management/account_management_page.tsx
x-pack/plugins/security/public/nav_control/nav_control_service.tsx
Outdated
Show resolved
Hide resolved
x-pack/plugins/security/public/nav_control/nav_control_service.tsx
Outdated
Show resolved
Hide resolved
0 | ||
); | ||
|
||
if (hasCustomProfileLink && passedCustomProfileLinkCount > 0) { |
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.
question: how do you feel about adding two simple unit tests for for these new if
branches?
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 feel like that is a good idea, however I do not have experience writing them 😬
A few options:
- I can create a separate issue for adding them later (post-merge)
- Perhaps you can point me at a simple example
- I hate to ask, but if its small and you have any time, could I ask you to add them? (here or post-merge)
Thanks for your feedback. It has been very helpful!
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.
No worries at all!
- Perhaps you can point me at a simple example
- I hate to ask, but if its small and you have any time, could I ask you to add them?
We have a couple of tests for nav_control_service.tsx
here and for nav_control_component.tsx
here. You can run them in a watch
mode with node scripts/jest --watch x-pack/plugins/security/public/nav_control/
.
But please don't waste too much of your time on this if you're stuck - just let me know and I'll push the tests to your branch my morning tomorrow and we'll merge it with a green CI. I'd prefer to keep the changes with the relevant tests in the same PR if possible.
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.
Thank you for the information. If you don't mind pushing in the morning, I would be very grateful and can learn from what you add here. My afternoon is, unfortunately, eaten up by a dentist appoint or else I'd make an attempt myself :/
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.
Done in b3b8872
@@ -122,37 +146,38 @@ export class SecurityNavControl extends Component<Props, State> { | |||
const isAnonymousUser = authenticatedUser?.authentication_provider.type === 'anonymous'; | |||
const items: EuiContextMenuPanelItemDescriptor[] = []; | |||
|
|||
if (userMenuLinks.length) { |
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 could get fancier here and so something like set an order value on the default profile link, but I'm not sure if/when we'd need that, thus the simpler approach.
Agree, makes sense to me 👍
// Set this as the first link if there is no user-defined profile link | ||
if (!hasCustomProfileLinks) { | ||
items.unshift(profileMenuItem); | ||
} else { |
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.
question: would you mind adding a simple unit test for this new behavior?
💚 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, thanks!
Many thanks @azasypkin !! |
* Update text and icons to align with Cloud * Update test to reflect new page title prefix * Change links conditionally * Simplify profile link logic * Add setAsProfile prop for overriding default link * Address feedback * remove translations since message has changed * Tidying up * Add unit tests. Co-authored-by: Kibana Machine <[email protected]> Co-authored-by: Aleh Zasypkin <[email protected]>
* Update text and icons to align with Cloud * Update test to reflect new page title prefix * Change links conditionally * Simplify profile link logic * Add setAsProfile prop for overriding default link * Address feedback * remove translations since message has changed * Tidying up * Add unit tests. Co-authored-by: Kibana Machine <[email protected]> Co-authored-by: Aleh Zasypkin <[email protected]> Co-authored-by: Kibana Machine <[email protected]> Co-authored-by: Aleh Zasypkin <[email protected]>
Fixes #82755
Summary
Updates the Kibana user menu links and icons to align with Cloud, as described in the related issue above.
For the sake of clarity, this PR is a small iteration on the existing menu labels, as we want to avoid ever having more than one link displaying the term 'Profile' [1]. A desired outcome of the larger, unified user profile effort seeks to avoid redundancy of user settings between a Kibana instance and Cloud. The contents of the current Kibana Account Management page, including how they will be impacted in the Cloud use case, are being hammered out in the User Profile/Settings project.
[1] While there is existing support for displaying Cloud links in the Kibana menu, these links are never displayed since the links are not currently being set in the
kibana.yml
file. Once those are provided by Cloud, the links will 'turn on'.Specifically, this PR...
setAsProfile
prop on the nav control component, allowing plugin authors to set a superseding Profile linkuser
tocontrolsHorizontal
(fwiw,gear
is already in use for Account & Billing)In the Cloud plugin...
setAsProfile
proplogoCloud
touser
(only displays when Cloud enabled)Menu when Kibana is self-managed
The Profile link opens the Account Management page in Kibana.
Menu when Kibana is hosted on Cloud
The Profile link takes you to the Cloud profile page.
The Preferences link opens the Account Management page in Kibana.
Current menu in the Cloud UI, for comparison
Design notes
For better alignment, we will need a few minor design adjustments on the Cloud side, as well. These suggestions largely align to the default
EuiContextMenu
styles:EuiPopover
propbuffer={0}
)Revised page title for additional clarification
To test
Checklist
Delete any items that are not applicable to this PR.