github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2026-05-07 03:58:09 -05:00
Code Issues 690 Packages Projects Releases 11 Wiki Activity

Make username optional #447

New Issue
Open
opened 2025-11-01 20:56:19 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2025-11-01 20:56:19 -05:00
Owner
Copy Link

Originally created by @vikunja-bot on GitHub (Apr 1, 2025).

Original issue by dpschen on 2023-04-06T11:04:53.000Z

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.

Original issue on Gitea

@kolaente commented on 2023-04-06T11:48:02.000Z:

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.

dpschen commented on 2023-04-06T13:04:49.000Z:

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.

@kolaente commented on 2023-04-10T11:40:47.000Z:

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.

dpschen commented on 2023-04-10T13:16:30.000Z:

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.

dpschen commented on 2023-04-20T17:22:12.000Z:

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

default view
image

expanded view
image

@kolaente commented on 2023-04-20T20:39:14.000Z:

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

dpschen commented on 2023-04-20T21:36:11.000Z:

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.

episode_grinch227 commented on 2023-08-28T11:10:48.000Z:

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.

@kolaente commented on 2023-08-29T12:13:27.000Z:

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.

Originally created by @vikunja-bot on GitHub (Apr 1, 2025). _Original issue by dpschen on 2023-04-06T11:04:53.000Z_ 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. [Original issue on Gitea](https://kolaente.dev/vikunja/vikunja/issues/1482) --- _**@kolaente** commented on 2023-04-06T11:48:02.000Z_: 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. --- _**dpschen** commented on 2023-04-06T13:04:49.000Z_: > 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. --- _**@kolaente** commented on 2023-04-10T11:40:47.000Z_: 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. --- _**dpschen** commented on 2023-04-10T13:16:30.000Z_: > 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. --- _**dpschen** commented on 2023-04-20T17:22:12.000Z_: 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) --- _**@kolaente** commented on 2023-04-20T20:39:14.000Z_: 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 --- _**dpschen** commented on 2023-04-20T21:36:11.000Z_: > 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. --- _**episode_grinch227** commented on 2023-08-28T11:10:48.000Z_: 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. --- _**@kolaente** commented on 2023-08-29T12:13:27.000Z_: > 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 Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
area/attachments
area/auth
area/avatars
area/backup-restore
area/caldav
area/calendar-view
area/comments
area/config
area/database
area/desktop
area/docker
area/email
area/favorites
area/filters
area/frontend
area/gantt
area/i18n
area/import-export
area/internal-code
area/kanban
area/labels
area/list-view
area/mobile
area/notifications
area/permissions
area/projects
area/pwa
area/recurring-tasks
area/reminders
area/search
area/shortcuts
area/subtasks
area/sync
area/table-view
area/task-editor
area/task-metadata
area/task-relations
area/teams
area/theming
area/time-tracking
area/typesense
area/views
area/webhooks
bug
changes requested
concern/accessibility
concern/performance
concern/regression
concern/ux
confirmed
db/mysql
dependencies
enhancement
good first issue
help wanted
integration/inbound
integration/outbound
kind/bug
kind/feature
needs reproduction
pull-request
Mirrored from GitHub Pull Request
 question
security
support
upstream issue
waiting for reply
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vikunja#447
Delete Branch "%!s()"

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?