Skip to content

Allow custom usernames.#106

Open
chusopr wants to merge 1 commit into
vexim:masterfrom
ultreia-es:custom-username
Open

Allow custom usernames.#106
chusopr wants to merge 1 commit into
vexim:masterfrom
ultreia-es:custom-username

Conversation

@chusopr

@chusopr chusopr commented Feb 9, 2016

Copy link
Copy Markdown
Contributor

We typically use vexim with customers that want to upgrade their existing ancient mail system, so we want to keep the same usernames they were using and, most of the times, they use a specific schema for usernames that they want to keep for new users (and that doesn't match e-mail address), so we need to be able to select what username to use when creating a new account.
This patch allows domain admins to select which username to use for new accounts. I don't know if you may be interested in merging it upstream, so I'm pushing it and feel free to reject it if you are not interested.

@chusopr chusopr mentioned this pull request Feb 9, 2016
@rimas-kudelis

Copy link
Copy Markdown
Collaborator

I have an idea. Why not make custom usernames a config option which could be enabled when necessary? Perhaps this could even be extended by allowing to choose from multiple predefined username schemas, and allowing to use a custom one if none of these predefined schemas work.

This way the "User name" field should only be displayed when custom usernames are selected instead of being always visible and always required. What do you think?

@Udera

Udera commented Feb 9, 2016

Copy link
Copy Markdown
Collaborator

On 2016-02-09 11:52, Rimas Kudelis wrote:

I have an idea. Why not make custom usernames a config option which
could be enabled when necessary? Perhaps this could even be extended
by allowing to choose from multiple predefined username schemas, and
allowing to use a custom one if none of these predefined schemas work.

This way the "User name" field should only be displayed when custom
usernames are selected instead of being always visible and always
required. What do you think?

Reply to this email directly or view it on GitHub [1].

Links:

[1] #106 (comment)
I like the idea to allow a customizable user names.

With this feature, we should retire the split username field during
login. The dropdown-menu reveals information about the server (can be
disabled) and it makes no sense for other username-schemes. Instead, I
would just use a singe username field. For webmail and IMAP/POP you
already do it that way.

@rimas-kudelis

Copy link
Copy Markdown
Collaborator

Yeah, why not.
@chusopr are you up for extending your patch? :)

@chusopr

chusopr commented Feb 15, 2016

Copy link
Copy Markdown
Contributor Author

Hi, sorry, I'm not very available right now. I'm moving to another country and changing my job, so I am in the middle of a lot of procedures.
Actually, this patch is a change I made months ago for internal use that I decided now to push upstream while I'm cleaning up my projects.

@ikonia

ikonia commented Feb 15, 2016

Copy link
Copy Markdown
Contributor

I really don't think custom user names are a priority for a release, I'd rather see less risk / change on optional features, and stabilisation of the task list for road to release before moving forward with more additional features

Matt

On 10 Feb 2016, at 6:19 am, Rimas Kudelis notifications@github.com wrote:

Yeah, why not.
@chusopr are you up for extending your patch? :)


Reply to this email directly or view it on GitHub.

@runout-at

Copy link
Copy Markdown
Contributor

I came around this issue on implementing a new WebUI in Python. (see https://github.com/vexim/vexim2/wiki/WebUI-GUI-in-Flask-Python3)

My idia is to use the username field only for login. In every place where the mail address of a user is needed, it should be constructed from concat_ws('@', users.localpart, domains.domain).
I didn't check if this would work properly with MDA logins (dovecot, courier,...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants