Document email usage in the api #6717
Conversation
itaiad200
added
the
v1.0.0-blocker
|
♻️ PR Preview 519214e has been successfully destroyed since this PR has been closed.
🤖 By surge-preview |
itaiad200
added
the
exclude-changelog
| email: | ||
| type: string | ||
| description: | | ||
| The email address of the user. If API authentication is enabled, this field is mandatory and will be invited to login. |
There was a problem hiding this comment.
Is it unique? (I assume not, but it pays to be explicit)
Is it case sensitive?
There was a problem hiding this comment.
@guy-har @Isan-Rivkin same here
There was a problem hiding this comment.
lakeFS doesn't have such restrictions, in most cases we connect with an external auth provider which does cause the email to be unique
There was a problem hiding this comment.
Added an explanation on APIAuthenticator enforcements.
| @@ -672,15 +672,21 @@ components: | |||
| properties: | |||
| id: | |||
There was a problem hiding this comment.
We should say how to present the user. I think it's display the first non-blank of friendly name, email, id. But I'm honestly not sure.
(Also now that anything except the last is non-unique! So probably good to display to the user themselves, but not so good to display in a list of users.
There was a problem hiding this comment.
@guy-har @Isan-Rivkin I need help answering this as the main consumers of this is us (Cloud, Enterprise)
There was a problem hiding this comment.
Currently, the behavior in the UI isn't consistent
when listing users we display the first non-blank of email, id
when showing the current user in the navbar we display the first non-blank of friendly name, id
IMO we should align them both to the first non-blank of friendly name, email, and id but still provide a way to see the ID.
Having that said, is this something that should be documented or just a client decision?
There was a problem hiding this comment.
Got it. Since we don't have any strict representation of the users, I would refrain from adding one to the API documentation. Once we'll have more alignment this can be revised. But until then - less is more.
closes #6684