Make username optional #1482

Open
opened 2023-04-06 11:04:53 +00:00 by dpschen · 9 comments
Collaborator

For unique identification we should use a unique id internally instead.

In order to display a title for the the user still needs some title and we don't want to share his mail as fallback the username is only optional if he has a name set and vice versa.

Possible alternative

Create a new field that acts as username (unsure what to call that internally) on which the rules above apply instead. For existing users we duplicate the value of the original username field.

For new users the original field could be automatically be populated by the name before the '@' in the mail or by a random id. For autocompletion we'll only complete with the new field, meaning if it is empty you have to reference that person via name or mail.

Further enhancements

This would potentially allow the user to change the username later (it's already allowed to change the 'name' property).
This could be implemented by replacing mentions of a username in saved texts with the users unique id (should probably be something longer like a uuid instead of the current autoincremented ids). Either in the frontend or before rendering that text we replace that unique id with a 'user' component in pill form.

For unique identification we should use a unique id internally instead. In order to display a title for the the user still needs some title and we don't want to share his mail as fallback the username is only optional _if_ he has a name set and vice versa. ### Possible alternative Create a new field that acts as username (unsure what to call that internally) on which the rules above apply instead. For existing users we duplicate the value of the original username field. For new users the original field could be automatically be populated by the name before the '@' in the mail or by a random id. For autocompletion we'll only complete with the new field, meaning if it is empty you have to reference that person via name or mail. ### Further enhancements This would potentially allow the user to change the username later (it's already allowed to change the 'name' property). This could be implemented by replacing mentions of a username in saved texts with the users unique id (should probably be something longer like a uuid instead of the current autoincremented ids). Either in the frontend _or_ before rendering that text we replace that unique id with a 'user' component in pill form.

An easy way out of this could be making the username field optional for new accounts and generating a username for new users. That's what we're already doing for openid authentication. I think we don't really use the username as a reference to a user at all internally.

The login would need to change so that we use the email instead of the username to log in (which works already, now it's just using both).

And we need a new method to mention users in comments, right now that uses the username as well.

An easy way out of this could be making the username field optional for new accounts and generating a username for new users. That's what we're already doing for openid authentication. I think we don't really use the username as a reference to a user at all internally. The login would need to change so that we use the email instead of the username to log in (which works already, now it's just using both). And we need a new method to mention users in comments, right now that uses the username as well.
konrad added the
kind/feature
label 2023-04-06 11:48:08 +00:00
Poster
Collaborator

And we need a new method to mention users in comments, right now that uses the username as well.

I would keep usernames as a feature and it's good that we have it. Because sometimes you want usernames and sometimes names (that could also be invented). And it's also good to have two options because a username might be simpler to remember than a real name if it's complex or you don't know how it was spelled.

and generating a username for new users

I had the following idea:

image

  • Reverse order of mail and username in register view.
  • Mark mail and password field required, because username will now be optional
  • pre-fill placeholder attribute of username form field with 'the part before the @ of the mail' and add something like "(generated)" to the label.
  • use the placeholder value when submitting the form
  • if the user didn't manually enter a username and it was already taken we add a suffix, like _1 to the the pre-filled placeholder value instead of showing a normal error. We do this to give the user again the option to change the name, because he might just have liked the pre-filled value.
> And we need a new method to mention users in comments, right now that uses the username as well. I would keep usernames as a feature and it's good that we have it. Because sometimes you want usernames and sometimes names (that could also be invented). And it's also good to have two options because a username might be simpler to remember than a real name if it's complex or you don't know how it was spelled. > and generating a username for new users I had the following idea: ![image](/attachments/c1c2a0b1-912b-4bde-9165-45973852e5f8) - Reverse order of mail and username in register view. - Mark mail and password field required, because username will now be optional - pre-fill placeholder attribute of username form field with 'the part before the @ of the mail' and add something like *"(generated)"* to the label. - use the placeholder value when submitting the form - if the user didn't manually enter a username and it was already taken we add a suffix, like `_1` to the the pre-filled placeholder value instead of showing a normal error. We do this to give the user again the option to change the name, because he might just have liked the pre-filled value.
1.7 MiB

This is a good idea. Generating the username from the email prefix will probably work, but we should think of a way to handle cases gracefully where a user with that username already exists.

This is a good idea. Generating the username from the email prefix will probably work, but we should think of a way to handle cases gracefully where a user with that username already exists.
Poster
Collaborator

This is a good idea. Generating the username from the email prefix will probably work, but we should think of a way to handle cases gracefully where a user with that username already exists.

See the last point in the list.

> This is a good idea. Generating the username from the email prefix will probably work, but we should think of a way to handle cases gracefully where a user with that username already exists. See the last point in the list.
Poster
Collaborator

Interesting how Slack handles this. Just found this at the bottom of their settings page:

default view
image

expanded view
image

Interesting how Slack handles this. Just found this at the bottom of their settings page: *default view* ![image](/attachments/f7d27af9-80c6-45b8-9d26-63e6eeb91b1b) *expanded view* ![image](/attachments/e0e1e648-e91e-4ebf-994a-06e84e51e84e)

What Slack does looks a lot like they had usernames in the past and are now not using them but can't remove them either because they're used as unique key everywhere

What Slack does looks a lot like they had usernames in the past and are now not using them but can't remove them either because they're used as unique key everywhere
Poster
Collaborator

What Slack does looks a lot like they had usernames in the past and are now not using them but can't remove them either because they're used as unique key everywhere

I guess that's the origin. Regarless they still have real world use because for tagging people a nickname feels better suited (beause of no spaces) I do know its not necessary. Sometimes you want to have a nickname and a real name. So I see its role now more like a property of the user info that is a nice feature.

> What Slack does looks a lot like they had usernames in the past and are now not using them but can't remove them either because they're used as unique key everywhere I guess that's the origin. Regarless they still have real world use because for tagging people a nickname feels better suited (beause of no spaces) I do know its not necessary. Sometimes you want to have a nickname and a real name. So I see its role now more like a property of the user info that is a nice feature.

For tagging, it could also be made possible, to use the real name (first name only). I like to have random usernames, so people wouldn't know how to tag me.

For tagging, it could also be made possible, to use the real name (first name only). I like to have random usernames, so people wouldn't know how to tag me.

For tagging, it could also be made possible, to use the real name (first name only). I like to have random usernames, so people wouldn't know how to tag me.

If you've enabled it, people can already search for your user by the real name (not yet for tagging, but that will come once we have the new editor). We still need some unique string to identify the tag, and since there can be multiple people with the same first name we can't use that.

> For tagging, it could also be made possible, to use the real name (first name only). I like to have random usernames, so people wouldn't know how to tag me. If you've enabled it, people can already search for your user by the real name (not yet for tagging, but that will come once we have the new editor). We still need some unique string to identify the tag, and since there can be multiple people with the same first name we can't use that.
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: vikunja/api#1482
There is no content yet.