console
console copied to clipboard
openshift
Masthead username toggle does not uses fullName
Just updated to 4.15.0-0.okd-2024-03-10-010116
The text at the top left corner of the console used to be my full name, now it just displays my username (my email) instead.
Is this intended behavior?
Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.
If this issue is safe to close now please do so with /close.
/lifecycle stale
Hi, is this is an intentional change. We can't always rely on having access to the user's full name with external OIDC providers, so we've changed the masthead to show the user's email address. Please let us know if this causes an issue.
/close
@spadgett: You can't close an active issue/PR unless you authored it or you are a collaborator.
In response to this:
Hi, is this is an intentional change. We can't always rely on having access to the user's full name with external OIDC providers, so we've changed the masthead to show the user's email address. Please let us know if this causes an issue.
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.
![openshift-ci[bot] avatar](https://avatars.githubusercontent.com/in/91280?v=4 "Published by a pub.dev verified publisher"){kind=small}
It can be nice to have the ability to choose what field will be shown there.
As an alternative, email can be shown as a fallback only if the full name is undefined/null
I work at a company where most of the user's emails are just meanless numbers and letters before the domain part, which says nothing to the user.
@spadgett
Let me reopen the issue, and we'll consider adding it back. Thanks for the feedback!
@jhadvig @alimobrem FYI
Stale issues rot after 30d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.
If this issue is safe to close now please do so with /close.
/lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity.
Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.
/close
@openshift-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue by commenting
/reopen. Mark the issue as fresh by commenting/remove-lifecycle rotten. Exclude this issue from closing again by commenting/lifecycle frozen./close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.
@logonoff: Reopened this issue.
In response to this:
/remove-lifecycle rotten /reopen
Still an issue
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.
I think this should be fixed as @ShaharIlany suggests (or at least partially).
I don't think it's a good idea to just hardcode the value to the name of the mapped value of the claim preferred_username (if the user comming from an OpenID for example). Different companies have different reasons on why they are mapping users various names. Internally you might just have an ID for exmple, which doesn't say anything about the user (similar to what @ShaharIlany describes).
Previously you actually displayed the value that was mapped to the claim name, which according to the documentaion here is suppose to be some sort of "Display Name" (which is what is being mapped to the fullName attribute on the User resource (user.openshift.io/v1)), which somewhat makes sense.
So to sum it up, I would suggest a couple of ways forward,
- If the User resource (user.openshift.io/v1) has populated the key
fullName(with whatever the user wants (today that value is being populated from theenameclaim if using OpenID)), use that value in the menu. - Make an option to allow the user to define which key from the User resource (user.openshift.io/v1) that should be displayed in the menu.
- Document the behaviour accordingly.
That's my two cents 💯🤷
