Create a company whoose name ends with a dot like "Bidule Inc.", change
the company of the user to that new company, head to the Accouning
module and create a new journal of type purchase. Traceback because the
generated mail alias for that journal uses the company name and that the
local-part of an email cannot ends with a dot.

From the RFC standpoint, the local-part of an email address (the part
before the @, `john` in `"John Doe" <john@example.com>`, cannot begins
with, ends with or contain following dots.

The email sanitizing function have been updated so it takes care of the
above requirement.

See also #61811
opw-2448692

closes odoo/odoo#69816

Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>

Before this commit

When someone tries to send a mail to a restricted alias (which can be
anywhere in 'To', 'CC' or 'BCC') and if the sender is not allowed to do
so, the mail bounces. However bounced mail shows info as if it bounced due
to address provided in 'To', even though it is not always the case.

Example you send a message to

  * 'To': 'valid@gmail.com' (okay)
  * 'Cc': 'myalias@odoo.com' (not allowed for you)

Mail bounces because you are not allowed to send a mail to alias provided
in 'Cc', but it shows the message that: `The following email sent to
valid@gmail.com cannot be accepted because [...]`.

After this commit

Boucing alias is shown in message body. Above example becomes `The following
email sent to myalias@odoo.com cannot be accepted [...].`

Note: Because the alias can be present in `Bcc` too (which will not available
in the message values we get in `message_route_verify` method), we simply use
display name of the alias instead of finding mail address matching with alias
from the message values.

Task ID-2390310

closes odoo/odoo#69752

X-original-commit: 1b17d68a192585317165d64babb6f9753b61c972
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Before this commit there would be `ValueError: Expected singleton:` error on
updating `alias_name` on multiple records at same time. Indeed constraint
does not allow batch computation. This commits fixes that behavior and now
constraint support recordsets with more than one record..

Fixes #65127

closes odoo/odoo#67333

X-original-commit: 16f42ff33f52705253071cf229f4ac575b8ed7e9
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

* Change the `addons/account/i18n/vi.po` PO file to replace the
translation of `Vendor Bill` like msgids from `Công nợ nhà cung cấp`
to ` by `Hóa đơn Nhà cung cấp`, there should be 3. What's matter is
the `đ` character.
* Create a brand new Vietnamese database (using `-l vi_VN` and
`--load-language=vi_VN`)
* Install Invoicing (`account`), an email alias constraint is raised.

> You cannot use anything else than unaccented latin characters in the
> alias address.

During the installation of the invoicing module, an email alias is
created for every journal account of purchase type. The alias is created
using the current journal name. Here the journal name is `Hóa đơn Nhà
cung cấp`, as mail aliases should only contain ascii characters, we
attempt to remove the accents. The `tools.misc.remove_accents`
successfully remove most of them but the `đ` character is left as-is,
the final alias is `hoa-đon-nha-cung-cap` which is invalid as it
contains some non-ascii characters.

The `remove_accents` function uses the [NFKD] Unicode Compatibility
Decomposition Normalization Form. This normalization process unify all
abstract equivalent characters, i.e. characters only different by font
or rotation. While this normalization process helps to transcript a lot
of characters to their ascii compatibility equivalent, some 118,230
other non-ascii characters (mainly from the Chinese and Japanese scripts)
are left as-is as they lack an ascii compatibility equivalent.

The solution has been to not use the journal name but rather the journal
code or journal type as email alias when the name is unsafe. The journal
code is a short version of the name, the journal type is not
translatable so is always ascii.

One additional watchdog has been added to the sanitization function of
email aliases so non-ascii characters are replaced with a '?' which is
an authorized character in emails local-part.

[NFKD] https://unicode.org/reports/tr15/

Closes #55492
Closes #55493

closes odoo/odoo#58276

X-original-commit: 8dc85be3821cf26226cd0bf4ce2b6739e68fc66f
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Co-authored-by: Thong Le <thongthele@users.no-reply.github.com>

Create a mail alias with non-ascii characters like 'foß', send an
email from your personal email account to that alias. The delivery fails
because Odoo SA servers don't support the SMTPUTF8 extension which is
required to parse the local-part ("display" <local-part@domain>) part of
a From header.

While external providers may create international, very weird, emails
and we should support receiving/sending emails from/to them. Our policy
is to only create very basic email addresses. That is all ASCII,
letters, digits and a limited set of punctuation characters.

Restricting what aliases can be created, we ensure no advanced extension
should be enabled on SMTP servers.

opw-2293336
Closes #53403

closes odoo/odoo#55166

X-original-commit: 4db3f21f52fa774ec651fc0b6eaa9a8652b2ae4c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>

This commit fixes all issues detected by the new pylint
gettext-variable test.
It converts some calls to the new syntax
  _("Foo %s", bar)

to progressively migrate the code to the new syntax.

A few calls were not technically incorrect but still detected by the
linter.

  _("Foo" +
    "Bar")

has been converted to

  _("Foo"
    "Bar")

as it has the same effect and make sure the argument is of type
asteroid.Const instead of BinOp).

closes odoo/odoo#53683

Related: odoo/enterprise#11467
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id

Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.

Purpose of this commit is to allow multi-create in alias mixin by correctly
creating / updating aliases in batch.

Task ID 1919277
Community PR odoo/odoo#41160
Enterprise PR odoo/enterprise#6983
Upgrade PR odoo/upgrade#872

Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>

Clean the usage of mail aliases and more specifically its associated mixin
`mail.alias.mixin` .

Stop using context for model of aliases, and correctly give model_id and
parent_model_id to the call chain through a cleaned code easier to override.

We also merge methods get_alias_model_name and get_alias_values in single one
called before record creation (alias first values) and right after (to have
values depending on actual record).

LINKS

Task ID 1919277
Community PR odoo/odoo#41160
Enterprise PR odoo/enterprise#6983
Upgrade PR odoo/upgrade#872

Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>

Purpose is to ease module understanding.

Task ID 2160070