[7.0] default user email alias does not preserve dots

Hi Jignesh,

Is it possible to send us a little video or to detail it a little more? It would help a lot finding the problem. Is it about incoming or outgoing emails?

I've tagged lp:1131182 as duplicate of this one. Still interesting to visit the description of that bug as it goes a bit further in the analysis of the issue.

personally i would rate the bug high not medium since it makes most of the chatter functions useless or even worse not reliable and this without any error message or anything else for the "normal" user.

A quick look in the openobject-server code grepping for email brought several different regular expressions used for the validation and / or extraction of emails. in ir_mail_server.py, tools/mail.py, res_partner.py. There are other regexps in openobject-addons (mail/mail_thread.py, ./crm/wizard/crm_lead_to_opportunity.py,

If you really need to handle email addresses with regexp, please provide a central, not too restrictive regexp (cf. http://davidcel.is/blog/2012/09/06/stop-validating-email-addresses-with-regex/) and use this single reference version throughout the code.

BTW, a likely culprit for this is the create_unique_alias function in mail/mail_alias.py, which does:

    alias_name = re.sub(r'[^\w+]', '-', remove_accents(vals['alias_name'])).lower()

I leave it to the Addons team 1 to confirm and fix.

Short answer: aliases are configurable, and by default dots (.) are replaced with dashes (-). You can simply edit the user alias to replace the dash with a dot.

Long answer:
The mapping between inbound "virtual inboxes" and actual database records is configured through "email aliases". The master table for aliases is accessible via Settings>Technical>Email>Aliases (this requires Technical Features access right). Each individual alias is also customizable on the corresponding record, and the system only chooses an initial value based on the record name.

For instance Projects are alias-enabled, so when you create a Project "Customer Support" the system will setup an alias <project+customer-support@yourcatchalldomain>. You can change the local part "project+customer-support" by editing the project at any moment, e.g. change it to simply "support@yourcatchalldomain". If the default alias is already taken, the system generates another unused variant.

OpenERP "Users" are also alias-enabled, but the local part of their alias is not editable by default because users are not expected to change it. However since OpenERP does not restrict the characters that can be used in user logins (e.g. "<3->" is a valid login), an automatic sanitization needs to be performed when initializing the default alias for users, and it currently only allows alphabetical characters and underscores (technically '\w', as quoted by Alexandre in comment #5).

We can of course change the sanitization code to allow dots, but we could also take it one step further. For instance GMail considers that "<email address hidden>" is the same as "<email address hidden>" and completely ignores dots in local parts. We could do that and ignore any dots not only when sanitizing aliases, but also when comparing aliases for uniqueness and when matching aliases while processing incoming mails.

In any case the local part of aliases is something that the admin can easily change and dots are allowed when set manually, so this is not a blocking issue.

Hope this helps..

If a '.' is an invalid character then as a minimum shouldn't it be blocked when adding a user?

Anyhow, I still suggest supporting '.' as it is a common user name for email addresses and customers will just want to maintain a universal username especially if they are using LDAP.

On 02/21/2013 11:58 PM, Jamie Perry wrote:
> If a '.' is an invalid character then as a minimum shouldn't it be
> blocked when adding a user?

As I explained it's neither invalid not unsupported, it's just not used by the
system when setting up the default email alias for users. You can manually
change that in aliases and it will work fine.
And we certainly won't change the rules of acceptable characters in usernames
just because we suddenly reuse the login for email aliases.

> Anyhow, I still suggest supporting '.' as it is a common user name for
> email addresses and customers will just want to maintain a universal
> username especially if they are using LDAP.

We purposefully do not restrict the allowed characters in usernames, so that
any existing login can be reused (be it LDAP or any other supported auth
mechanism). There is no reason to change that.

We can however consider it as a character that we preserve unmodified when
generating aliases, just like '-', '_', A-Z, a-z or 0-9.

Thanks Olivier for the clarification and explanation of what is at hand.

Thanks Oliver, it make sense the username is used to default the email alias field.

In light of Messaging being a major feature of 7.0, what about having the Email Alias field in the standard "Users" page now?

This will also make the translation of '.' into '-' more apparent.

On 02/22/2013 11:37 AM, Jamie Perry wrote:
> In light of Messaging being a major feature of 7.0, what about having
> the Email Alias field in the standard "Users" page now?
>
> This will also make the translation of '.' into '-' more apparent.

As far as I can see this is the case already: as soon as you enable the aliases
feature by setting a "Mail Catchall Domain" in Settings>Configuration>General
Settings, the alias becomes visible on the User form as well as on any
alias-enable document (Projects, HR Jobs, CRM Sales teams, Mail Groups)

"We can however consider it as a character that we preserve unmodified when
generating aliases, just like '-', '_', A-Z, a-z or 0-9."

I really would do this since i think it solves a lot of problems in the real world where the dot is really often used in company e-mail addresses.

The fix has landed in addons 7.0 at revision 8900 (revision-id: <email address hidden>).

It has 2 effects:
 - dots will now be preserved in default user alias (or in any other default alias generated by the system)
 - when the user login has the form of an email, only the local part will be preserved when generating the alias - e.g. a user with login '<email address hidden>' will have a default alias of 'john.doe'. This is mostly useful for external/portal users. Aliases must be unique so if another user already has alias 'john.doe', the new one will have 'john.doe2', etc.

Keep in mind that this is only when generating default aliases, it is always possible to modify them manually.

Thanks for reporting and for your patience!