Make username optional #1482
Labels
No Label
dependencies
duplicate
help wanted
invalid
kind/bug
kind/feature
needs reproduction
question
security
wontfix
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: vikunja/vikunja#1482
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
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.
I had the following idea:
_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.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.
Interesting how Slack handles this. Just found this at the bottom of their settings page:
default view
expanded view
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.
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.