TestMailCommon was an empty class in test_mail kept for backward compatibility
while MailCommon is in mail. This is needed as we plan to move test_mail in
another addons path in order to isolate test addons.
Task-3263512
Part-of: odoo/odoo#117606
Warn user and alias responsible when model creation fails on incoming
message due to alias mis-configuration.
Alias custom default values that references archived or deleted records can
prevent the record to be created when receiving an email.
Unfortunately, correcting values on the fly has too many downsides:
- as the value cannot come from nowhere, we would probably end up with
corrupted record like a task without a project
- as errors are silent, lots of suboptimal record could be created before it
is corrected
- as the code would have to deal with different kind of updates, it would be
heavily depend on the framework meaning additional maintenance cost
- the attempt made had also a performance cost by using savepoint which we
want to avoid
For all those reasons, we have decided to warm the user rather than trying to
solve the problem automatically.
The users are warned:
- through a bounce email sent to the sender and alias responsible
- in the alias interface through an alias status present in the list and the
form view
Technical notes:
- They are multiple kind of errors: error in the message (ex.: user not
authorized to send to a specific alias), error in the alias (ex.: dangling
reference in alias_defaults), other error (ex: technical error like a
service unavailable when receiving the message). Here, we want only to detect
alias error and skip other errors. So rather than doing a big try except around
_message_route_process, we have selected the spot where we should detect alias
error:
-- in _alias_get_error_message where we distinct a message error from an alias
error
-- in inside _message_route_process where record are created using
alias_defaults (custom values with reference to record that might have been
deleted since the alias creation)
- In test, we call mail.thread message_process with sudo as it is the case in
real use case (processed when fetching mail). It is needed as in some test
alias status are modified.
Task-2675209
closesodoo/odoo#101019
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If a list of emails is bigger than 500, the email was sent several
time to some people.
The mail_values content was not reset between each batch, so if 1200
emails are sent, 3 mail.mail records were created for the emails in
the first group.
closesodoo/odoo#93658
X-original-commit: f838a0cc36e51e0f47daeec6522df8e9832aad2c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Change all masculine nouns in Odoo's code to neutral nouns (when
possible), making sure that demo data is correctly handled. This is
particularly important since our code is open source, and nowadays lots
of machine learning models are trained on open source repositories.
With this small change we contribute to training more "fair" models, and
teaching models that "employee" or "user" != "he".
This also affects some text visible by the user, hence making it more
inclusive for Odoo users.
Task-2853046
closesodoo/odoo#91292
Related: odoo/enterprise#27302
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
When trying to identify the user sending an email, do not match anyone
without email.
Sometimes we get an email without a valid From address (spammers or
bugs), the previous code was trying to find users with this email.
In historical databases, we often have many users without an email
address, they should not match the search.
This commit fixes two bugs:
_mail_find_user_for_gateway:
No longer match on the first res.users with no email when identifying
the user using the gateway. This was not problematic (as we have a
fallback on self._uid anyway) but it is more accurate for tracebality
of emails.
_find_members
This method is called from _alias_get_error_message to verify that the
sender is indeed in the group with the followers restriction. On large
mailing list, it is not uncommon to have members with empty emails
(migration, historical reasons,...). Sending an email without any From
was matching on these subscribers without email and the email was
accepted.
These emails are invalid and should not be accepted.
closesodoo/odoo#83122
X-original-commit: 8ec7b92467da2856a496210af1f2232eba6bafb4
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In v15, in _find_members, we try to find a members with an email and without
partner_id or a member with the partner_id provided (if provided).
This commit remove the author_id, and so the partner_id to only looking for
members based on their email address.
Author_id could be the wrong since email is not uniq on partner.
We retrieve the same behavior than previously from this way.
courtesy of std for help to find a solution
closesodoo/odoo#80638
X-original-commit: 98d7b1417ee82fefcef175dd83ab41cd89db5119
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Purpose
=======
This commit improves the UI of the mail group module (backend and portal
view), fix some bugs and clean the code.
Bug 1
=====
If a user click 2 times on a confirmation link, an error is raised.
Bug 2
=====
A bug about the website snippets has been fixed;
- Add the snippet to a group in which you are member
- Change the group of the snippet to a group in which you are not member
- The snippet still show "Unsubscribe"
Bug 3
=====
In the portal view, when messages are filtered by month, messages which
are created in the last day of the month appear also in the next month.
Specification
=============
UI
--
Show the Allow / Ban buttons whatever is the state of the message, so
the user can ban / whitelist a message even if there's no pending email.
When we receive an email, remove the "Mailing List" footer. This was a
big issue because when some users reply many times, the footer was
duplicated on each answer.
Improve the form view of the mail group:
- On non-moderated group, show all messages instead of only pending
message
- Show the guidelines stuff on non-moderated groups
Improve the portal view
- show the attachments under every message (not only on opened message)
- improve the template to confirm the subscription of the user
- improve the portal view for mobile device
- do not show rejected messages, even for admin
- do not show the button "X replies" when the mode is not thread
Technical
---------
Split the route "/groups/subscription" into "/group/subscribe" and
"/group/unsubscribe"
Correctly quote the parent email for the emails sent by web version of
Outlook (with the HTML id "divRplyFwdMsg").
ACLs
----
Now only administrators or responsible / moderators can write / unlink
the group.
Fix an ACL issue on the group member where the responsible of a
non-moderated group could not access the members of the group.
Members with same email
-----------------------
Improve the behavior when multiple members have the same email address
(this situation is possible because there's no unique constraint on the
email field of the <res.partner> model.) We now return the most
appropriate member for the given email address and partner.
When unsubscribing by clicking on the confirmation link that we received
by email, remove all members with the same email address.
Links
=====
Task-2599676
See odoo/odoo/pull/73640
closesodoo/odoo#73640
Related: odoo/upgrade#2774
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
The purpose of this new module is to manage the mailing lists. Now they
are no more <mail.channel> (will email_send set to True) but they have
their own model.
Specifications
==============
The mailing list are basically a public discussion that users can have
by email. They can respond to email, send new messages, etc... All the
members of the mailing list will receive the message by email.
Users can moderate the emails of the mailing list in the same way as
they did with the "email" mail channel.
- *accept*, will accept the emails and send it to the members of the
mailing list
- *discard*, will drop the email without warning the author
- *reject*, will drop the email and send a notification email to the
author
- *allow*, will accept the email and all other pending emails of the
same author and create a whitelist for him
- *ban* will drop the email and all other pending emails of the same
author and create a blacklist for him
Now a portal view is available (in /groups) and replace the old module
"Website Mail Channel" that was removed in the previous commit. In this
view, users can subscribe / unsubscribe to the mailing lists and some
links to this portal view are added in the footer of the emails of the
mailing list.
As before with mail channels, you can send guidelines to the members,
notify the moderators whose an action is required (in a CRON), send back
an email to the author of an email to say "Your message is waiting
moderation"...
Links
=====
Task-2510267
See odoo/odoo/pull/71599
See odoo/enterprise/pull/19296
See odoo/upgrade/pull/2600
Martin Trigaux