Underscore on username #831

New Issue

OVERLORD · 2026-02-04T21:26:40+03:00

OVERLORD commented

2026-02-04 21:26:40 +03:00

Originally created by @intersecato on GitHub (Oct 6, 2025).

I noticed that you can't create users whose usernames end with an underscore. Is this a design choice for some reason, or is it a bug? Even just logging in with OIDC results in a generic error.

Originally created by @intersecato on GitHub (Oct 6, 2025). I noticed that you can't create users whose usernames end with an underscore. Is this a design choice for some reason, or is it a bug? Even just logging in with OIDC results in a generic error.

OVERLORD closed this issue

2026-02-04 21:26:43 +03:00

OVERLORD commented

2026-02-04 21:26:49 +03:00

@nastyagrifon commented on GitHub (Oct 7, 2025):

Can confirm that entering username with underscore at the end and pressing "Add user" does not create the user. Happens only with username.

ghcr.io/plankanban/planka:2.0.0-rc.4

@nastyagrifon commented on GitHub (Oct 7, 2025): Can confirm that entering username with underscore at the end and pressing "Add user" does not create the user. Happens only with username. `ghcr.io/plankanban/planka:2.0.0-rc.4`

OVERLORD commented

2026-02-04 21:26:54 +03:00

@intersecato commented on GitHub (Oct 7, 2025):

I also noticed that the username can't even begin with an underscore, not just at the end.

@intersecato commented on GitHub (Oct 7, 2025): I also noticed that the username can't even begin with an underscore, not just at the end.

OVERLORD commented

2026-02-04 21:26:56 +03:00

@kekekuli commented on GitHub (Oct 9, 2025):

I looked up the source code for validating the form of adding user, the logic is under the file validator.js in utils folder. You can see the regex here

const USERNAME_REGEX = /^[a-zA-Z0-9]+((_|\.)?[a-zA-Z0-9])*$/;

Planka is using this regex to test if the username avaliable. The regex don't allow underscore stand at start or end.

So the conclude is that this is a design choice

@kekekuli commented on GitHub (Oct 9, 2025): I looked up the source code for validating the form of adding user, the logic is under the file **validator.js** in **utils** folder. You can see the regex here `const USERNAME_REGEX = /^[a-zA-Z0-9]+((_|\.)?[a-zA-Z0-9])*$/;` Planka is using this regex to test if the username avaliable. The regex don't allow underscore stand at start or end. ### So the conclude is that this is a design choice

OVERLORD commented

2026-02-04 21:26:58 +03:00

@kekekuli commented on GitHub (Oct 9, 2025):

I think there would easily cause confuse like this issue due to currently have not sensiable tips to tell user what's wrong. Currently, the only feedback PLANKA provide is to put the focus to the field that failed validation. @meltyshev

@kekekuli commented on GitHub (Oct 9, 2025): I think there would easily cause confuse like this issue due to currently have not sensiable tips to tell user what's wrong. Currently, the only feedback PLANKA provide is to put the focus to the field that failed validation. @meltyshev

OVERLORD commented

2026-02-04 21:27:02 +03:00

@kekekuli commented on GitHub (Oct 9, 2025):

I think there would cause confuse like this issue due to currently have not sensiable tips to tell user what's wrong. Currently, the only feedback PLANKA provide is to put the focus to the field that failed validation.

Even the focus feedback have not vibrant color like red.

@kekekuli commented on GitHub (Oct 9, 2025): > I think there would cause confuse like this issue due to currently have not sensiable tips to tell user what's wrong. Currently, the only feedback PLANKA provide is to put the focus to the field that failed validation. Even the focus feedback have not vibrant color like red.

OVERLORD commented

2026-02-04 21:27:06 +03:00

@intersecato commented on GitHub (Oct 9, 2025):

I looked up the source code for validating the form of adding user, the logic is under the file validator.js in utils folder. You can see the regex here

const USERNAME_REGEX = /^[a-zA-Z0-9]+((_|\.)?[a-zA-Z0-9])*$/;

Planka is using this regex to test if the username avaliable. The regex don't allow underscore stand at start or end.

So the conclude is that this is a design choice

But is there exactly a concrete reason why this was chosen? Do accounts with an underscore at the beginning or end cause problems? It was precisely the lack of valid error messages that made me think it wasn't intentional.

@intersecato commented on GitHub (Oct 9, 2025): > I looked up the source code for validating the form of adding user, the logic is under the file **validator.js** in **utils** folder. You can see the regex here > > `const USERNAME_REGEX = /^[a-zA-Z0-9]+((_|\.)?[a-zA-Z0-9])*$/;` > > Planka is using this regex to test if the username avaliable. The regex don't allow underscore stand at start or end. > > ### So the conclude is that this is a design choice But is there exactly a concrete reason why this was chosen? Do accounts with an underscore at the beginning or end cause problems? It was precisely the lack of valid error messages that made me think it wasn't intentional.

OVERLORD commented

2026-02-04 21:27:12 +03:00

@kekekuli commented on GitHub (Oct 9, 2025):

I looked up the source code for validating the form of adding user, the logic is under the file validator.js in utils folder. You can see the regex here
const USERNAME_REGEX = /^[a-zA-Z0-9]+((_|\.)?[a-zA-Z0-9])*$/;
Planka is using this regex to test if the username avaliable. The regex don't allow underscore stand at start or end.

So the conclude is that this is a design choice

But is there exactly a concrete reason why this was chosen? Do accounts with an underscore at the beginning or end cause problems? It was precisely the lack of valid error messages that made me think it wasn't intentional.

Yeah. I agree with you, but I don't know the motivation, may be meltyshev will give the answer.

Lack of valid error messages, you said, that is the problem

@kekekuli commented on GitHub (Oct 9, 2025): > > I looked up the source code for validating the form of adding user, the logic is under the file **validator.js** in **utils** folder. You can see the regex here > > `const USERNAME_REGEX = /^[a-zA-Z0-9]+((_|\.)?[a-zA-Z0-9])*$/;` > > Planka is using this regex to test if the username avaliable. The regex don't allow underscore stand at start or end. > > ### So the conclude is that this is a design choice > > But is there exactly a concrete reason why this was chosen? Do accounts with an underscore at the beginning or end cause problems? It was precisely the lack of valid error messages that made me think it wasn't intentional. Yeah. I agree with you, but I don't know the motivation, may be meltyshev will give the answer. Lack of valid error messages, you said, that is the problem

OVERLORD commented

2026-02-04 21:27:15 +03:00

@meltyshev commented on GitHub (Oct 9, 2025):

Hey! Sorry for the late reply. The username format was initially chosen without considering that OIDC would be introduced later, so yes - it's a bit outdated and we can update it. We might even consider removing the validation at the model level so it can accept any username coming from the provider, but we'll need to test this first. Also, I completely agree - there's definitely a lack of error messages in the OIDC process.

@meltyshev commented on GitHub (Oct 9, 2025): Hey! Sorry for the late reply. The username format was initially chosen without considering that OIDC would be introduced later, so yes - it's a bit outdated and we can update it. We might even consider removing the validation at the model level so it can accept any username coming from the provider, but we'll need to test this first. Also, I completely agree - there's definitely a lack of error messages in the OIDC process.

OVERLORD commented

2026-02-04 21:27:17 +03:00

@intersecato commented on GitHub (Oct 15, 2025):

We might even consider removing the validation at the model level so it can accept any username coming from the provider

If possible, we'd be very happy. There are many users in our community whose usernames begin or end with an underscore who are currently blocked.

@intersecato commented on GitHub (Oct 15, 2025): > We might even consider removing the validation at the model level so it can accept any username coming from the provider If possible, we'd be very happy. There are many users in our community whose usernames begin or end with an underscore who are currently blocked.

OVERLORD commented

2026-02-04 21:27:19 +03:00

@meltyshev commented on GitHub (Oct 15, 2025):

I just made it less strict (/^[a-z0-9._-]*$/) at the model level. Didn't want to remove the format validation entirely, since that could cause bugs - for example, if a username contains an @ symbol.

You can try updating to the nightly version so you don't have to wait for the final v2 release - just don't forget to switch back to the stable one once it's ready.

@meltyshev commented on GitHub (Oct 15, 2025): I just made it less strict (`/^[a-z0-9._-]*$/`) at the model level. Didn't want to remove the format validation entirely, since that could cause bugs - for example, if a username contains an `@` symbol. You can try updating to the `nightly` version so you don't have to wait for the final v2 release - just don't forget to switch back to the stable one once it's ready.

OVERLORD referenced this issue

2026-02-04 21:49:49 +03:00

[PR #776] [MERGED] feat: Added mobile support #1095

OVERLORD referenced this issue

2026-02-04 21:51:09 +03:00

[PR #831] [MERGED] Update core.js #1113

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/planka#831