We have our own html2plaintext, already used in lot of use cases instead of
just a few for the html2txt library.
Notably for emails: most emails going through Odoo stack use our simple
html2plaintext to format the body alternative. When no body alternative
is given to ``build_email`` an alternative is built using the library to
remove. Using our own parser allows to have the same results compared to
using ``MailMail.send()``. Difference lies in spaces and new lines as well
as markdown. Our html2plaintext is a bit simple and does not try to generate
Markdown but generates a simple plaintext version.
This also helps solving some issues with depending on that library.
Task-2702034
closesodoo/odoo#82486
X-original-commit: b3b9627b655cd7cb928925affed6cc8d92661e8d
Related: odoo/enterprise#23364
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
When there are multiple databases on a single server, it is necessary
to be able to set the "from_filter" for the implicit SMTP server
on a per-database basis, to allow 'opt-in' to the automatic wrapping
of email notifications.
When set to e.g. `notifications@example.com`, and a default SMTP
server is defined in the server-wide config or CLI, outgoing emails
will be automatically rewritten to come from this email, unless the
From/Return-Path domains match the `mail.catchall.domain` parameter.
Task-2710632
closesodoo/odoo#81277
X-original-commit: 8b468e1f7a3dfeb2bcfa83bff55c4b5adf6b2212
Signed-off-by: Olivier Dony <odo@odoo.com>
* add configuration for `flake8[flake8-rst-docstring]`
* enable docstring-related checks
* fix invalid docstrings in odoo's core & `base`
* fix a few more bits (mostly missing or incorrect `:param:` info
fields) are out of scope for the lint but my editor catches
closesodoo/odoo#74604
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
PURPOSE
Help people setuping their mail server with clear labels and form view.
SPECIFICATIONS
Rename Description to Name, as Description indicates a secondary text
field. Add a placeholder to indicate it is used as a functional name
and not a technical field.
Relabel the field for filtering to FROM Filtering. Current From Filter
could lead to think it filters incoming emails which is not the case.
Move button for testing in header as on all form views.
Use radio buttons for authentication and encryption to display available
settings directly to user. This is more user friendly than selection boxes.
Split connection information in two groups: authentication and security.
Each group comes with its options below main radio-based field.
Task-2628092
closesodoo/odoo#76301
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
=======
We want to increase the score of the emails sent by Odoo and we want to
avoid them to be marked as spam by the mail clients (gmail, outook...).
SPECIFICATIONS
===============
From filter
-----------
Add a new field on the "ir.mail_server" which is "from_filter". This
field defines the email address for which the outgoing email server can
be used.
The "from_filter" can either define an email address or a domain name.
Use the system parameter "mail.default.from" which allow us to define
a default email address which is used to encapsulate the emails
(default: notifications@<catch.all.domain>).
Mail server priorities
----------------------
When sending an email, we read the FROM header and,
- We first look for a mail server which match the entire mail FROM
in that case, we do not change the email header (not needed)
- If not found, we search a mail server which matches the domain name of
the mail from (do not need to change the headers in that case)
- If not found, find the mail server linked to the "notifications"
email (defined in the system parameter). Then change the FROM header
to the notification email, and put the old one in the name part of
this header.
E.g.
Initial mail from: "Admin" < admin@example.com >
Final mail from: "Admin (admin@odoo.com)" < notifications@odoo.com >
- If no notification email is configured or if no mail server are
found for the notification email, fallback to the old system and
spoof the FROM header. In that case we do not have the choice if we
want to send the email, he will probably be marked as spam.
Sending method priority
-----------------------
In the mail server models, we defined some priorities,
1. Forced SMTP session
2. Forced mail server
3. Try to find the best mail server (see "Mail server priorities")
4. If not found, read the odoo-bin arguments
Bounce
------
As there's no standard for bounce address, we put it in the envelope
(smtp_from). But in some case, it might be considered as spoofing. So,
we use the bounce address ONLY if the mail server is configured for the
entire domain name.
One behavior which might be broken is the following; we send an email as
"std@gmail.com" and the bounce address is on the domain "odoo.com".
Before we received the bounce notifications but we were spoofing the
local part and the domain.
Now
- if a mail server is configured for GMAIL, we do not use the bounce
address (and we might not receive the bounce notification)
- if no mail server is configured for GMAIL, but one is configured for
"odoo.com"
- the FROM header will be "notifications@odoo.com"
- the FROM envelope will be the bounce address
=> In this situation we are spoofing only the local part of the email
but it's allowed as the mail server is configured for the entire
domain name
LINKS
=====
Task-2367946
odoo/odoo#61853odoo/upgrade#1903
Purpose
=======
Split the code of "send_email" in "ir.mail_server" so the changes will
be easier to review.
Task-2367946
odoo/odoo#61853odoo/upgrade#1903
PURPOSE
=======
We want to be able to authenticate our servers with a certificate
for the entire domain name instead of using a username and a password.
SPECIFICATIONS
==============
Add 2 fields on the `ir.mail_server`, which are
- the SSL certificate
- the SSL private key
When we uploaded both files, we use them to authenticate the client of
the SSL connection.
Add 2 options on the Odoo binary, so we can provide the filenames of both
files (like we do for the SMTP username/password).
SETTINGS
========
Note that this type of authentication doesn't work locally for Microsoft
office 365. It seems like Microsoft is blocking non-static IP address
(not able to ping the host locally, but it works on the server).
The host name of the server is defined in the MX DNS record. Then, on
Office 365 you must create an SMTP relay based on a certificate and not
based on a hard coded IP address. The certificate must be valid for your
domain name.
e.g.
Host: openerp-org.mail.protection.outlook.com
Port: 25
Username: <keep it blank>
Password: <keep it blank>
Security: STARTTLS
Email: admin@odoobe.com
New Python dependence
=====================
The standard SSL python library only takes a filename to the certificate
/ private key.
But, we do not want to use attachments and take the full path to the
file (in the filestore) or to create temporary file.
So, we need to use a new library "PyOpenSSL" which allows you to load
a certificate / private key from a byte array.
To make this library work with SMTPLIB we use a wrapper developed
in urllib3 (PyOpenSSLContext).
LINKS
=====
Task-2367946
odoo/odoo#61853odoo/upgrade#1903
Purpose
=======
Revert the commit a757cab857
because the rewriting of the FROM of the emails sent will
be done in a smarter way in master.
Task-2367946
odoo/odoo#61853odoo/upgrade#1903
Purpose
=======
We want to be able to force the FROM headers when we sent email in
SMTP. So we can avoid the emails to be considered as spam.
Specifications
==============
This is done with 2 system parameters.
If the system parameter `mail.force.smtp.from` is set we encapsulate all
outgoing email from with the given value.
If the previous system parameter is not set and if both
`mail.dynamic.smtp.from` and `mail.catchall.domain` are set, we
encapsulate the FROM only if the domain of the email is not the same as
the domain of the catchall parameter.
Otherwise we do not encapsulate the email (same behavior as before this
commit).
Task 2367946
See odoo/odoo/pull/61853
closesodoo/odoo#70980
X-original-commit: 08a561505b92d23c4c4ec4094b0cee209ece8753
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Bug
===
1. Create an event which allows track proposal
2. Follow it and subscribe to "New Track"
3. Log in in incognito and submit a proposal
The email is not sent, because it's sent as the public user, which has
no email address set. And so it the 2 system parameters
<mail.catchall.domain> and <mail.default.from> are not set, we can not
know which email address used to send the email.
Note that this bug also occurs if you create a track with a user without
an email address set.
Task 2510181
closesodoo/odoo#70627
X-original-commit: 45ffab08a7c1dacc70d331077198f92884b53646
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Settings > Technical > Email > Outgoing Mail Servers;
- Create a new serve with no security;
- Test connection.
Before this commit, a traceback error is raised. This occurs because
SMTPException don't have 'smtp_error'.
Now, the UserError is shown correctly.
opw-2464796
closesodoo/odoo#67712
X-original-commit: f0e478a154b1f15146c7d95e0ffe146bb22b8cae
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
WHY: PEC server rejects default addresses, so you cannot test connection
---
opw-2371431
closesodoo/odoo#65516
X-original-commit: 876d3b3b8cf9f91a3609871f69b3ce1186d71ac6
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Configure an email server and create a login account with a space like
"foo bar". In odoo configure an Outgoing mail server using that account,
there is an error because the username is misconsidered invalid.
The errors resides in the IDNA implementation of Odoo, we try to split
the username to get a login and a domain in order to encode the domain
using the ponycode algorithm. In case the username was not an email
adress but just a single name, the single name was mistaken for a
domain. As domain cannot have spaces, an error was thrown.
opw-2419024
closesodoo/odoo#64885
X-original-commit: 61b0a859b76ebffe083e10b25e4af52702dfb61f
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
The emails sent via Odoo reveive a poor score on various spam tools,
the reason being the missing `MIME-Version` message header. This header
inform what MIME version is in use in the message. Even if there is only
one standardized version of MIME (1.0), the header is mandatory.
Citing [rfc2045] "MIME: Format of Internet Message Bodies" section 4:
> the MIME-Version header field is required at the top level of a message.
Setting the charset on the envelop forces the EmailMessage API to also
include the missing `MIME-Version` header.
[rfc2045]: https://tools.ietf.org/html/rfc2045#section-4
Task 2393865
closesodoo/odoo#64715
X-original-commit: 8663f1e20727c315924bb20fc1de1accf3014c61
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
There is a user whose email login is "joe@examplé.com", notice the
latin "é" in the domain. This domain is a valid IDNA-2008 domain but
the smtplib of python is incompatible with such domain and raises a
UnicodeError because the character is not ascii.
Note the removed comment about bytestring is a leftover of a dark
python2 age and is no more valid.
Closes#61972closesodoo/odoo#62026
X-original-commit: 89a1989bd271f49a9222d5c255e03d4877045621
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
This commit improves the notification displayed when we configure
the mail server and click 'Test Connection' button. It removes the
title of the notification, improves the message string and changes
the notification type to 'success' instead of default 'warning'.
Task Id : 2321763
PR #56213
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Ease the configuration of external email servers by adding links to the
documentation and by making errors more user friendly.
SPECIFICATIONS
This is done by catching more exceptions when testing outgoing mail server
connection and giving related hints.
A link to the documentation is also added in mail: Settings > External Email
Servers feature: add a link to this doc: https://www.odoo.com/documentation/user/13.0/discuss/advanced/email_servers.html
Task ID-2273671
PR #54176
X-original-commit: d30682f4d4aeaefa077ba284a60c93f3a020365f
Python 3 before 3.8 has a bug that causes the email.policy classes to
incorrectly fold and RFC2047-encode "identification fields" in email
messages. This mainly applies to Message-Id, References, and In-Reply-To
fields.
We are impacted by this bug since odoo/odoo#35929 where we switched to
using the "modern" email.message API.
RFC2047 section 5 clearly states that those headers/fields are not to be
encoded, and that would violate RFC5322.
Further, such a folded Message-Id is considered non-RFC-conformant by
popular MTAs (GMail, Outlook), which will then generate *another*
Message-Id field, causing the original threading information to be lost.
Replies to such a modified message will reference the new, unknown
Message-Id, and won't be attached to the original thread.
The solution we adopt here is to monkey-patch the SMTP policies to
special-case those identification fields and deactivate the automatic
folding, until the bug is properly and fully fixed in the standard lib.
Some considerations taken into account for this patch:
- `email.policy.SMTP` is being monkey-patched globally to make sure we
fix all possible places where Messages are being encoded/folded
- the fix is **not** made version-specific, considering that even in Python
3.8 the official bugfix only applies to Message-Id, but still fails to
protect other identification fields, like *References* and
*In-Reply-To*. The author specifically noted that shortcoming [2].
The fix wouldn't break anything on Python 3.8 anyway.
- the `noFoldPolicy` trick for preventing folding is done with no max
line length at all. RFC5322, section 2.1.1 states [3] that the maximum
length is 998 due to legacy implementations, but there is no provision
to wrap identification fields that are longer than that. Wrapping at
998 chars would corrupt the header anyway. We'll just count on the
fact that we don't usually need 1k+ chars in those headers.
The invalid folding/encoding in action on Python 3.6 (in Python 3.8 only
the second header gets folded):
```py
>>> msg = email.message.EmailMessage(policy=email.policy.SMTP)
>>> msg['Message-Id'] = '<929227342217024.1596730490.324691772460938-example-30661-some.reference@test-123.example.com>'
>>> msg['In-Reply-To'] = '<92922734221723.1596730568.324691772460444-another-30661-parent.reference@test-123.example.com>'
>>> print(msg.as_string())
Message-Id: =?utf-8?q?=3C929227342217024=2E1596730490=2E324691772460938-exam?=
=?utf-8?q?ple-30661-some=2Ereference=40test-123=2Eexample=2Ecom=3E?=
In-Reply-To: =?utf-8?q?=3C92922734221723=2E1596730568=2E324691772460444-anot?=
=?utf-8?q?her-30661-parent=2Ereference=40test-123=2Eexample=2Ecom=3E?=
```
and the expected result after the fix:
```py
>>> msg = email.message.EmailMessage(policy=email.policy.SMTP)
>>> msg['Message-Id'] = '<929227342217024.1596730490.324691772460938-example-30661-some.reference@test-123.example.com>'
>>> msg['In-Reply-To'] = '<92922734221723.1596730568.324691772460444-another-30661-parent.reference@test-123.example.com>'
>>> print(msg.as_string())
Message-Id: <929227342217024.1596730490.324691772460938-example-30661-some.reference@test-123.example.com>
In-Reply-To: <92922734221723.1596730568.324691772460444-another-30661-parent.reference@test-123.example.com>
```
[1] bpo-35805: https://bugs.python.org/issue35805
[2] https://github.com/python/cpython/pull/13397#issuecomment-493618544
[3] https://tools.ietf.org/html/rfc5322#section-2.1.1closesodoo/odoo#55656
X-original-commit: 02b78770147e2eda65a76d29c6f2fc3278581b22
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
It has been a recurrent request from customers to be able to send email
messages to email addresses containing non-ascii characters. [IDNA] is a
domain extension to allow unicode characters in domain names. [SMTPUTF8]
is a SMTP extension to allow unicode in any header.
IDNA defines the [punycode] encoding which translates unicode to an
ascii representation. This encoding MUST be used to encode domains.
SMTPUTF8 is an SMTP extension that allow utf-8 in all headers on the
envelope.
[IDNA] https://tools.ietf.org/html/rfc5890
[SMTPUTF8] https://tools.ietf.org/html/rfc6531
[punycode] https://tools.ietf.org/html/rfc3492
Task: 2116928
opw-2229906
opw-2248251
closesodoo/odoo#47709
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
TL;DR: remember `osv` and `except_orm` ? You can forget about them.
* Deprecated `except_orm` dropped.
* `UserError` elevated as super type of all user-related
errors.
* Unused `DeferredException` dropped.
* Unused `QWebException` dropped (real one is in `qweb.py`).
* `MailDeliveryException` made a python exception.
* `name` legacy exception attribute made an alias of the python standard
`args[0]` attribute and deprecated.
* `value` legacy exception attribute dropped.
* `exception_type` RPC error response key dropped.
* Deprecated `osv` module dropped.
* `--osv-memory-age-limit` cli option made an alias of
`--transient-age-limit` and deprecated.
The `odoo.exceptions.Warning` have long been a deprecated alias to
`UserError`. It is going to be removed in a future version but first we
explicitly deprecate it with a warning.
The `odoo.exceptions.DeferredException` was a very old internal
exception, it has been removed without deprecation notice as it is never
raised.
The `odoo.exceptions.except_orm` has been a deprecated exception type
with deprecation warning for 5 years, it has been removed in favor of
UserError which becomes the super class of all user-related errors.
The `odoo.base.models.ir_mail_server.MailDeliveryException` was
inheriting `except_orm`. As it is not related to a user error but is
more of a problem an admin much take care of, the exception has been
made a Python error.
The `exception_type` JSON key in RPC error responses was holding an
hardcoded value derived from the exception type. Its usage has been
dropped in favor of the `name` JSON key that holds the precise exception
name. Again as it was hardly used in the source code (beside the crash
manager) it has been dropped without deprecation warning.
Since we are here trying to clean odoo custom exceptions, we are also
deprecating the `name` exception attribute in favor of the more standard
`args[0]` attribute.
The `name` (along with `value`) were two attributes used to raise
`except_orm` exceptions before the introduction of `UserError`,
`AccessError` and related exceptions. The `name` attribute, at the time,
was holding the exception type/title. Nowadays it contains the error
message. The `value` attribute, at the time, was holding the error
message. Nowadays it is no more used.
The `osv` module contains very old deprecated aliases. There is no
simple way to log a deprecation warning for osv, osv_memory and
osv_abstract but as they have not been in use for ages, they have been
removed too. To be consistent, the `--osv-memory-age-limit` cli option
has been made a deprecated alias to the `--transient-age-limit`.
closesodoo/odoo#45723
Task: 2187728
Related: odoo/enterprise#9162
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Problem description:
Using the chatter, send an email to someone having non-ascii characters
in their name: the body of the received email looks like it contains
a mix of the original body and headers.
Python encodes the name into either base64 or quoted-printable but
leaves some redundant carriage returns at the end of the header. Those
redundant carriage returns are not RFC conformant but are interpreted
as newlines by some email clients, thus are read like a headers/body
separator and the next headers are considered part of the body,
corrupting the email structure.
This problem is internal to Python and has been fixed in 3.8, cfr
bpo-34424 [1], and later backported to 3.7.4. As we also support 3.6
and earlier 3.7 and it is not possible to easily monkey-patch the
function, we fixed it by squashing duplicate carriage returns.
(There is no case where a series of bare CRs can occur in a normal
RFC5322 email message)
Task: 2003936
[1]: https://bugs.python.org/issue34424
It is possible to get to a situation where Odoo would try to send an email without a `From:` header address.
In such case, you're unlucky if you don't have access to the underlying deployment, or if you use multiple databases in a single Odoo instance and each of them uses a different mail configuration.
To make this configuration easier to use and cover those use cases, here I add support for a new ICP: `mail.default.from`. It will be used when present, so it shouldn't affect existing deployments. When present, it will allow a admin to configure the default sending address just with Odoo itself.
closesodoo/odoo#38874
X-original-commit: 5010ce630a7f0e01d45d99c9083318b50f9f624a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
After the refactor of mail sending with the newest python API
(18299d7e50),
the order of multipart/alternative was wrong for email.
Indeed, in the MIME protocol [1], for The Multipart/alternative subtype
the order is significant: "In general, user agents that compose
multipart/alternative entities should place the body parts in increasing
order of preference, that is, with the preferred format last".
This bug caused some issues with mail marketing (see related task)
with Gmail web client (see the plaintext instead of html mail).
The fix is to inverse the order of adding alternative in the mail
content.
[1] https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
TASK_ID : 2084989
closesodoo/odoo#38490
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, in base we use bus to notify the user but bus module
is not always installed and so we can't call it.
After this commit, now we use a client action to notify the success test.
Steps to reproduce:
* install a Odoo with no apps
* go in debug mode
* go to "Outgoing Mail Servers" technical settings
* create a valid SMTP record
* click on "Test Connection" button (BUG)
closesodoo/odoo#38709
X-original-commit: ea4113745024a72bd170d9ceef38e97acd420d4e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
[PEP 594] is going to depreciate the legacy `email.message.Message` API
and its related modules: `email.(charset|header|mime|utils)`.
The new `email.message.EmailMessage` API exposes a much easier interface
to create multiparted emails [1], is capable of doing all the necessary
headers value conversion (RFCs [2045], [2047], [2049]) [2] and get/set
different flavor of payload (text/bytes) in a straightforward way [3].
All headers are structured in a way to support python native types, i.e.
the `Date` header supports `datetime.datetime` objects and automatically
performs the required formatting. The same goes for multi-valued headers
like the `To` header, one can directly set a python list of values, it
will be automatically be formatted according to the RFCs.
The dedicated encoding and decoding functions are no more needed thus
has been removed has part of the refactor. FTR, [RFC2231] is an update
of [RFC2047] and based on tests we've just conducted, both GMail and
Thunderbird now support RFC2231 encoding just fine in all headers:
attachments names, From, etc.
[1]: http://docs.python.org/3/library/email.message.html
[2]: http://docs.python.org/3/library/email.headerregistry.html
[3]: http://docs.python.org/3/library/email.contentmanager.html
[2045]: https://tools.ietf.org/html/rfc2045
[2047]: https://tools.ietf.org/html/rfc2047
[2049]: https://tools.ietf.org/html/rfc2049
[2231]: https://tools.ietf.org/html/rfc2231closesodoo/odoo#35929
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
If the connection test to mail server succeeds, we shouldn't see
"Oops something went wrong" and "User Error" either
Replace error generation to display success message by bus notify.
closesodoo/odoo#35292
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
* account, crm, hr, im_livechat, l10n_ch, l10n_it_edi, mail,
mass_mailing, project, stock, base
- `String` -> `string`;
- `defaut` -> `default`;
- `defaults` -> `default`;
- `reandonly` -> `readonly`;
- removed redundant `placeholder` attribute for `Char` field;
- removed redundant `size` attribute for `Float` and `Integer` fields;
- changed to use `Selection` instead of `Char` for a field having a
defined `selection`.
closesodoo/odoo#35356
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
smtplib.SMTP API calls such as .sendmail() or .login() make sure on
their first line that this command is sent, by calling
.ehlo_or_helo_if_needed().
However, test_smtp_connection() does not use SMTP.sendmail() to simulate
sending email, or the email would really be sent.
Instead it uses the low-level API SMTP.mail() which does not make sure
that HELO was sent.
The connection test could be fixed by ensuring that this command was
sent to the server in the test method. However, this could lead to
inconsistent cases where the connection test passes whereas another
usage in the code fails because the command was not sent.
For example, someone could use the low-level API for some reason.
EHLO could have already been sent because if authentication is enabled
smtplib.SMTP.login() calls ehlo_or_helo_if_needed(). Therefore it is
correct to call it ourselves at the end of our connect() method.
STARTTLS sends a first EHLO, negociates the encryption, and leaves the
state without the second EHLO, which should still be sent to the server,
as stated by RFC 3207, in section "4.2 Result of the STARTTLS Command".
https://www.ietf.org/rfc/rfc3207.txtclosesodoo/odoo#34550
Signed-off-by: Julien Legros (jle) <jle@odoo.com>
If the smtp session was dead, it would lead the whole mail batch to fail.
opw 1949270
closesodoo/odoo#32424
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
This commit replaces calls to pycompat helpers that were intended for
python 2 <-> python 3 interoperability for python 3 builtins, as python
2 is no longer officially supported by Odoo.
This includes:
* calls to imap/izip/ifilter replaced by map/zip/filter
* uses of text_type replaced by str
* uses of unichr replaced by chr
* calls to implements_to_string, implements_iterator removed
* string_types and integer_types replaced by str, int respectively
* calls to to_native replaced by calls to to_text
This is done in preparation to the removal of these deprecated helpers
in the following commit.
The ir.mail_server Model includes a sequence field, promising that the
lower sequence number have higher priority when multiple server
configurations are available.
The servers are already used based on that parameter since 00bd7274c4 but this
was not enforced at the _order level.
Make it coherent everywhere
closesodoo/odoo#28313
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
The "connection test" was only attempting to establish a socket to the
SMTP server and then trying to login, if credentials were setup.
This would catch basic config errors but would fail to detect setups
were the SMTP server would forbid relaying, because of missing
credentials, missing STARTSSL mode, and other more complex cases.
By actually beginning a real SMTP session and sending the MAIL FROM,
RCPT TO and DATA command, we make sure that the server appeas willing to
relay emails from the current user address to an arbitrary recipient
address. Then we close the session before actually sending the message.
In order to have a valid destination domain with a valid MX server, we
use an odoo.com recipient address for the test, which should prove that
the destination server will relay to arbitrary addresses (unless the
destination server is an Odoo.com MX server ;-))
When an exception is raised during the course of a normal SMTP session,
smtplib's `sendmail()` method will close the channel automatically,
so any further attempt at sending SMTP commands will fail with an
SMTPServerDisconnected error, even just calling `smtp.quit()`.
This will shadow the original error, and make debugging harder.
Fixes#1493
Purpose of this commit is to prevent unauthenticated access on user name
and password of the mail server. Indeed as mass mailing users notably gain
access to mail servers let us protect its credentials.
This commit is related to task ID 31737
Purpose of this commit is to not set parentheses around mail server name.
Indeed it does not add any value to have its ID in the name_get.
This commit is related to task ID 31737
Thibault Delavallée