Purpose
=======
A field `use_google_gmail_service` has been used in stable to define
a mail server which use Gmail authentication.
But now that the fields `smtp_authentication` exists, we want to use it
to simplify the mail server form view. For the incoming mail server,
the field `server_type` will be used for the same purpose.
Add a new field to have the option to install `google_gmail` in the
main settings page.
Task-2170676
closesodoo/odoo#83413
Related: odoo/upgrade#3199
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Less secured apps are no longer supported by google, therefore, we need
to transition to the OAuth2 authentication system.
Specifications
==============
1. User will need to fill their Gmail API credentials in the main
settings page
2. Then, in the incoming / outgoing mail server form view, they will
need to tick the Gmail support checkbox
3. A link will be available to be redirected to Gmail and accept the
permission
4. The user can now copy / paste the authorization code in Odoo, set
his email as "login" and then send / receive emails with Gmail
Task-2170676
closesodoo/odoo#83424
X-original-commit: ff223afc5300b2421b8ce935bb468f503c938c5d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In 72cd8d076 there was an improvement for removing infinite loop in POP
mail server, but if there was no message to fetch, you can get an error:
UnboundLocalError: local variable 'num' referenced before assignment
because `num` is not set when logging stats of fetching mails.
`num` should be set to 0 by default, we don't want to have it unset or
use a value from a previous loop.
opw-2724216
closesodoo/odoo#82582
X-original-commit: 7b3b623cf3359ac1eea537177f7f963e81403a01
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
- Set up a POP account
- On the POP account, receive emails addressed to various recipients,
e.g. `my_alias_1` and `my_alias_2`. Receive more than 50 emails to
`my_alias_2`.
- In Odoo, create a mail alias for `my_alias_1`
- Run the fetchmail cron
The cron runs endlessly until it is killed. In the logs, inconsistent
messages are shown:
```
...
Fetched 3507 email(s) on pop server xxx; -16493 succeeded, 20000 failed.
Fetched 3507 email(s) on pop server xxx; -16543 succeeded, 20050 failed.
...
```
First the message count is incorrect in the log. We fetched at most 50
emails, not the total number of emails. Then, the endless loop is due
to the fact that
- we do not delete failed messages (= messages addressed to
`my_alias_2`)
- we always fetch messages from `num=1`
If the first 50 messages fail, we fetch them endlessly until the cron is
killed.
To avoid this, we compare the number of failed messages with the number
of messages retrieved. If all messages retrieved have failed, we stop
the loop.
After the fix, consistent messages are show in the logs and the process
stops after the first complete failure:
```
start checking for new emails on pop server xxx
Fetched 50 email(s) on pop server xxx; 0 succeeded, 50 failed.
```
Note that it doesn't solve the core of the issue; we just fail faster. A
proper way would probably be to use an offset so we don't always start
at `num=1`. On the other hand, it is just a matter of time before the
cron times out: if the mailbox is full of messages which canot be
treated, we will just spend more and more time trying to find the ones
which can be treated.
closesodoo/odoo#81493
X-original-commit: 72cd8d0769097b21bbf94a34496888617058cb1b
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
currently, in fetchmail while create an incoming
mail server, Set a server name while being in POP
or IMAP server type and Switch to "Local" server type
the server name is erased.
with this commit, the value of the server name
should not be erased with onchange.
closesodoo/odoo#69250
Taskid: 2258523
X-original-commit: cf102783b43a44a38565768129ef414758a71fc6
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
See merge commit for more details.
Note that mail.alias model will be done in a separate commit.
Task ID-2330149
COM PR odoo/odoo#61246
ENT PR odoo/enterprise#14561
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 incoming mail server
connection and giving related hints.
Task ID-2273671
PR #54176
X-original-commit: f0ebeb96a05abc76d2acb77707a79f40e6999375
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.
This attribute is misleading as it is insufficient to correctly upgrade
the database. It only renames the column in the database, but other
operations are needed, like updating the corresponding `ir.model.fields`
record (and its xmlid). The default values and the translations are also
lost during the upgrade.
Moreover, this feature was misused. It was:
- left on fields during multiple versions.
- used on reports (SQL views). This would be ok if the feature was
complete, but, as is, it was useless.
- kept unchanged after a second renaming of the field (which can happen
versions later the first rename).
- used, even when the meaning of the field changed. i.e. the field
`archived` has been renamed to the classic `active`, but the value
in the database should be switched.
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'`
The purpose of this commit is to clean the user interface of local incoming
mail server and also update the script field default value
and configuration as per new script (from openerp_mailgate to odoo-mailgate).
task-1891157
closesodoo/odoo#33072
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Purpose: small cleaning of code linked to mail.mail model in order to
avoid unnecessary overrides
* create mail: default_fetchmail_server_id in context should be sufficient
as it is the base mechanism of default_get;
* write: unused in codebase. Anyway we should not write on mail and if it
is the case giving fetchmail_server_id directly should be the correct
way of doing it;
In case of a clean_context use we might loose default_fetchmail_server_id
key. It is used notably for tracking message generation. In that case
this information could be lost. However the whole concept of propagating
a fetrchmail_server-id from incoming mail server to outgoing emails (as
mail.mail is used only for sending email) is strange and does not require
so much specific code.
Sub-part of task 1853147 (pre-cleaning before implementing mail gateway
improvements)
Linked to PR #32974
Purpose of this commit is to rename type column to something matching the
the real business use of the field. That way it is easier to find and grep
in the code. It also lessens potential conflicts with type build-in python
function. It also lessens conflicts when using the field in JS as type
is a build-in attribute.
Renaming type column is a long-living issue. We choose to do it at the
beginning of the v13 development to catch errors as soon as possible.
This commit is linked to task ID 1896245. It is also a subpart of community
PR #27599.
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
Incoming email servers have an action_id field holding a server action to
run on newly created records. It comes from old implementation of mail
gateways in Odoo. Since then mail gateway has evolved. Incoming mail servers
are not linked to a unique model anymore. With aliases and automatic thread
creation mails can create records in various models.
As the server action is bound to a given model it causes issues. Either
we have to give back the result of the mail gateway processing to ensure
models match. Either we have to limit action_id to records created
using the "default model behavior" of incoming mail servers.
We choose to remove this field. Same result can be achieved with an
automated action running on create trigger. If exactly the same
behavior is intended the following rules should be applied
* add automated action with model linked to the one you want to
update depending on alias configuration and work flow;
* set trigger to create;
* set action as python;
* if it is necessary to be linked to the mail gateway, check in
record message_ids that there is a message with message_type
being 'email' meaning it has received an incoming email;
Using that heuristic migrating existing fetchmail action to server actions
should be quite straightforward and will give more flexibility.
This commit is linked to task ID 58641. Closes#23621 .
std-odoo