On the right panel of the mail editor, the icons of the mass mailing
module do not match with the other icons. We will then update them to
improve the consistency of the layout. The icons will now have the same
background color as the other icons.
task-2658133
Co-Authored-By Carlos Valverde <cvs@odoo.com>
closesodoo/odoo#78645
X-original-commit: 8aa5c39c0ba84a4e5bdb27ff6d70a43ad90ae4af
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Recently, [1] broke the style of a few snippets, because it was adding a
:not selector to the parent css class, that was used to define children
classes that were adding a suffix to the parent class name with the &
symbol.
It was decided that every snippet css class should be explicitly
declared to avoid breaking the style when adding selectors to the parent
class. This will also prevent breaking the style when adding a new css
version for the snippet.
task-2660921
[1]: https://github.com/odoo/odoo/pull/77312closesodoo/odoo#78413
X-original-commit: af6785599358d2dcb9ff811afc2e558a94d9704d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When writing on more than one record (e.g. via
_process_mass_mailing_queue cron)
X-original-commit: b18614bf99df47de77650f431e2062b8d2eacd06
Part-of: odoo/odoo#78259
Before this commit:
- UTM campaigns are accessible for all internal users, but with email
marketing related modules installed, if user who does not have rights
for email marketing tries to access the campaign, an AccessError is
raised. It's because few fields related to email marketing are added
in model `utm.campaign` which are accesible only to the marketing
users.
- When the user is having `mass_mailing.group_mass_mailing_campaign`
group enabled but no rights for email marketing, the root menu of
for the 'Email Marketing' app is visible to that user, which is
not correct.
With this commit:
- While adding marketing related fields to the campaign, we provide the
group("mass_mailing.group_mass_mailing_user") at field level whenever
neccessary so it doesn't raise AcessError. Also, we show those fields
on the campaign views only when `mass_mailing.group_mass_mailing_campaign`
group is enabled for the user. To do this, a compute field has been
introduced to make sure that user has rights to access email marketing
as well as the feature to manage mass mailing from campaigns is enabled.
The reason behind introducing a new compute field is, at view level,
it is not possible to check that user is having multiple groups.
- We've applied the group "mass_mailing.group_mass_mailing_user" on the
root menu of Email Marketing app, so if the user has UI only group
"mass_mailing.group_mass_mailing_campaign" and but no rights for
email marketing, the root menu won't won't appear.
TaskID-2417993
closesodoo/odoo#74113
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*: mass_mailing, website, website_sale
Before this commit, it was impossible to add `fa-fw` directly on a
`we-button` as it would make the icon half invisible, since the whole
`we-button` would have the font-awesome `.fa-fw` css rule applied on it;
width: ~1.28em.
Then, one would need to insert a `<i/>` tag inside the `we-button` for
it to work.
This commit improves that behavior by handling automatically such cases,
and will preserve the purpose of the `fa-fw` class which is to have a
fixed width for those icons.
Note that the util class introduced in [1] (o_we_button_icon renamed
here in o_we_icon_button) is still useful to handle the case of svg
images, they are not allowed to shrink, the same way the fa buttons are.
[1]: https://github.com/odoo/odoo/commit/e4233643b93b521454cc146c6a2ae876781fb9ba
Related to task-2172311
closesodoo/odoo#77980
X-original-commit: e8ab9d76b802e80bb386812e4c8566825cbc2c92
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Younn Olivier <yol@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
The body of a mailing is saved in two fields: body_arch without
modifications, and body_html with conversion for email client
compatibility. Prior to this commit, we were showing body_html when
opening the form view of a saved mailing in readonly. This was pretty
strange and confusing as it's a sort of intermediary version that
doesn't mean much: an in-browser rendering of html that is compiled for
email clients.
With this commit, we change the view to always show body_arch instead.
A new tab is introduced in order to show body_html for debugging, which
is therefore only visible in debug mode.
Part-of: odoo/odoo#77724
The css of some website snippets conflicted with their mass_mailing
equivalents. A quick, non-intrusive solution had been to contain that
css so it wouldn't conflict. This replaces that solution with the more
neighborly renaming of said snippets in mass_mailing. This way there is
no added awareness of mass_mailing within the code of website.
Part-of: odoo/odoo#77724
Commit [1] copied a lot of website snippet options into mass mailing.
Some were moved to web_editor and xpathed to be used in both without
duplicating code. Sadly that is not without side effects and it was
therefore decided to duplicate them instead so they can live separate
lives in the future.
[1] https://github.com/odoo/odoo/commit/4f7cd33d0fd69ee5984d0968233ffc73d7751030
Part-of: odoo/odoo#77724
This commit is there to be reverted in master. It temporarily restores
templates previously removed so as not to break migrations.
- s_mail_block_banner
- s_mail_block_title_sub
- s_mail_block_paragraph
- s_mail_block_comparison_table
- s_mail_block_two_cols
- s_mail_block_three_cols
- s_mail_block_image_text
- s_mail_block_text_image
- s_mail_block_image
- s_mail_block_footer_separator
- s_mail_block_steps
- s_mail_block_discount2
task-2554899
X-original-commit: d49b1942d33a222ac9159e76f7931cb89a85016f
Part-of: odoo/odoo#77724
This adds a series of CSS styles to the `<head>` of mailings in order to
ensure better mail client compatibility.
task-2554899
X-original-commit: ace475defca0c143d707f7b53d9f19a9db6cfe3e
Part-of: odoo/odoo#77724
This applies a default background color to all HTML mailings in order to
emphasize the separation between the mailing itself and its body.
task-2554899
X-original-commit: 75cbf5a559f891546c92f9079eb4d8dd22ac5e6b
Part-of: odoo/odoo#77724
This adds an empty template to `mass_mailing`, in which snippets can be
dropped, to start an HTML mailing from scratch.
task-2554899
X-original-commit: 7522272f42b38ef2f47e2432660bcf6a3030795c
Part-of: odoo/odoo#77724
Transparency is not supported in several leading mail clients. This adds
the option to completely remove transparent colors from the palette, and
uses that option in `mass_mailing`.
task-2554899
X-original-commit: 4e2c859b6d4fb8d9c12e24d1c8ebc84aa0f3c72e
Part-of: odoo/odoo#77724
Prior to this commit, it was possible to drop snippets out of the
confines of the mailing's body and into its editable parent instead.
This makes that impossible.
task-2554899
X-original-commit: e3942e4aa1391ca82a946d4b6b3823d2690733ee
Part-of: odoo/odoo#77724
`mass_mailing_table_item` was charged with ensuring proper cloning and
removing of table elements precisely because `mass_mailing` relied so
heavily on them. Since it doesn't anymore, there is no need for that
option. This removes it.
task-2554899
X-original-commit: 386848568adb8e11f57e458cb7862cb3058b07c9
Part-of: odoo/odoo#77724
The new automatic conversion from Bootstrap grid to tables allows us to
convert `mass_mailing` templates from their old table structures to
Bootstrap grid (as the reverse conversion will now be applied on save).
General heuristic for the conversion of templates:
| **Table** | **Bootstrap** |
|:-------------------:|:------------------------------------------:|
| `<table>` | `<div class="container">` |
| `<thead>` | _(removed)_ |
| `<tbody>` | _(removed)_ |
| `<tfoot>` | _(removed)_ |
| `<tr>` | `<div class="row">` |
| `<th>` | `<div class="col o_col_head">` |
| `<td>` | `<div class="col">` |
| `<td width="_n_%">` | `<div class="col-_o_">` where o ~= 12n/100 |
| `cellspacing` | _(removed but always added back to table)_ |
| `cellpadding` | _(removed but always added back to table)_ |
| `border` | _(removed but always added back to table)_ |
Some styles had to be changed to account for the difference in the HTML.
task-2554899
X-original-commit: c26dac24c5fd15165935c770175c1b6f87aaad41
Part-of: odoo/odoo#77724
This brings a series of improvements to the mechanism in place to
convert the output html of mass mailing into html that is more compliant
with the main mail clients' requirements.
The biggest change is the automatic conversion of Bootstrap grids into
table structures. Currently all templates in `mass_mailing` are designed
with tables so they work in mailings as is. That has limitations though
as it makes it less easy to edit with snippets such as those used in the
website builder. This new automatic conversion from Bootstrap grid will
allow us to adapt the mailing and snippet templates and be more free
within `mass_mailing`.
Note: Because of the limited support of media queries in emails, this
doesn't support the mixing and matching of column options
(e.g., `"col-4 col-sm-6"` and `"col col-4"` aren't supported).
Other changes include:
- The conversion of Bootstrap cards to table structures
- The conversion of Bootstrap list-groups to table structures
- The conversion of snippets (.o_mail_snippet_general) and mailings
(.o_layout) into table structures
- The conversion of all rgb colors to hexadecimal
- The conversion of all "rem" sizes to "px"
- Various small corrections to the output styles
task-2554899
X-original-commit: e2e00939e09220051f6f4ecfb7bb3276105387bf
Part-of: odoo/odoo#77724
"Rounded" and "Flat" buttons didn't have their proper styling
if the website module was not installed.
Styles for rounded and flat buttons have been added to theme_default.scss
closesodoo/odoo#77661
X-original-commit: 74540364428e9d5a308a1012ae8614aa37ecb8a6
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
On the CRM module, the user can send an email to all the contacts
associated to the leads matching some criteria by (1) displaying the
list view, (2) applying a search filter, (3) clicking on the "EMAIL"
button and (4) checking a checkbox on the mail composer to ask the
server to use the active search. To do the same thing, the user can
(1) display the list view, (2) apply a search filter, (3) select all
the records and (3) click on the "EMAIL" button.
To avoid redundancy and improve the usability of the composer, we will
remove the search domain passing from the mail composer. Note that it
will still be possible to pass a search domain programmatically.
To improve the guidance of the mail composer, we will add helper
messages, update the labels and move the options in a dedicated pane.
The wording of the buttons will also be updated dynamically based on
the selected options.
Example: When the user enters something in the `mass_mailing_name` field
to create a new mass mailing campaign from the new message, the label of
the "Send" button will be set to "Send Mass Mailing" which gives more
indication on what will happen when the user clicks on it.
task-2523036
Part-of: odoo/odoo#71413
Jinja as a templating engine was problematic in differents respect:
- introduce external dependency to Odoo (less controll)
- add another templating mechanism in the stack
- specific feature in qweb cannot be reused
- difficulty in rendering easily editable templates
- more knowledge required with no betterment
By replacing jinja with qweb we can now build tools to edit a qweb
that will work with the previously jinja encoded document
(essentially `mail.template` records).
There is a catch however. Some email fields (eg. email_to) used jinja
syntax for rendering dynamic variables (ie. ${object.something} and
${object.something_that_should_not_be_escaped | safe}).
We still want user to use dynamic variables for some char fields (eg.
subject, from, to, ...). We made a new rendering engine called
"inline_template" that will render an expression enclosed by `{{` and
`}}`.
To be able to edit the templates from the backend interface, a
plugin to the Odoo editor has been made for seamlessly edit the
document.
This qweb plugin includes:
- make dynamic variables (eg. `<t t-out="variable"/>`) not editable
(for preventing the user to shoot himself in the foot)
- group and hide related logical branching (ie. t-if, t-elif, and t-else)
in order to see only one at once
- a floating select input to switch visibility of a particular logical
branching
Task-27033
X-original-commit: odoo/odoo@68182baff4
Part-of: odoo/odoo#77377
Currently we are getting all records of mailing.mailing instead of
getting only records with mailing_type=mail. This bug was produced
by commit[1].
Now we have computed only that records which have mailing_type = mail,
So we can get perfect count in mail stats button in campaign.
commit[1] -> odoo/odoo@3f6625ef13
Task-2417993
closesodoo/odoo#76622
X-original-commit: 4f2924c5fcab672882ca78a9e6eb38b363d2d1b3
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Some assets are missing from layout due to an incorrect namespace
since conversion to new assets system.
opw-2638542
closesodoo/odoo#76238
X-original-commit: b55cb521f9b0abc98877e9e57b81c2d6eb6ca35c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
344d82c renamed `resetHistory` into `historyReset` but failed to update
some calls to it and rename its equivalent in wysiwyg.js. This commit
corrects the discrepancy.
Part-of: odoo/odoo#75901
When saving a mailing, we do some processing (converting classes to
inline styles mostly) in order for the mailing to display properly in
all email clients. Until we started saving the processed version
separately from the unprocessed version, we had to revert the process
whenever we would start editing the mailing. This was extremely
expensive and made the loading of a previously created email very, very
slow. This was kept so far for backward compatibility reasons 3 years
ago (see f296992). This commit removes the that unnecessary conversion.
Part-of: odoo/odoo#75901
Since the introduction of Odoo Editor, `field_html`'s `_getValue` uses
`wysiwyg.getValue`. This conflicts with the mechanism of `mass_mailing`
which modifies the html of the editable area in place to save an
"e-mailable" version on the `body_html` field, then relies on
`_getValue` to reset the original html (`body_arch`).
This ensures the field has a value before modifying the html in place,
so we can manually restore it instead of relying on a side effect of the
old behavior of `_getValue`.
Part-of: odoo/odoo#75901
Purpose of this commit is to globally improve code performance by limiting
search impact by
* adding limits when only first found record id used;
* avoid unnecessary searches when record set can be filtered instead;
* using cache when accessing ir.model;
Task-2638444
PR odoo/odoo#76005
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Co-Authored-By: Victor Feyens <vfe@odoo.com>
Manage correctly a/b testing in mass_mailing.
We can now organize a mass_mailing campaign by testing
multiple mailings for the recipients targeted (subject,
templates, design, ...)
For this a new tab on the mailing record is added to better
promote the existence of the feature.
When an user has the group to manage mailing campaign, he can
access the tab A/B Test. This tab allows to enable A/B testing
for the mailing. If there is no campaign set for the mailing,
one is automatically created allowing the user to continue
smoothly.
Once A/B testing enable, the percentage of recipients use can be
set for each mailings. Also, the user can choose the deciding factor
that will set the final mailing as winner.
In a case, the user is not in manual mode, he can set the schedule datetime
for sending the final mailing.
task-2123242
COM PR: odoo/odoo#75622
ENT PR: odoo/enterprise#20454
UPG PR: odoo/upgrade#2781
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
We clean various graph archs taking into consideration that:
- the default type of a graph is "bar".
- a bar chart is by default stacked.
- the field attributes type="row" and type="col" does not make sense for
a graph view (since its implementation was separated from the pivot
implementation a long time ago))
- the boolean attributes should now take 1 or 0 as value (but the other
values are accepted for retrocompatibility).
Part-of: odoo/odoo#76065
Purpose
=======
Purpose of this commit is to add a new group for the mail template designer.
Goal is to make roles clearer: managers edit templates, users use them. This
commit allow some designers / managers to make email template and to let
others users use those email templates.
Specifications
==============
When this feature is enabled in the Settings page, a new group is required to
modify email templates in a composer like wizard or to make dynamic content.
This allows to separate managers editing / composing templates from standard
users that use them.
If the current does not have this group, the email body will be in readonly
mode if he selected an email template. That way we force him to use the email
template that the manager made.
Technical
=========
New Group
---------
Only users in this group will be able to create / write email template or
to write Jinja code in the mail composer (including other fields like subject
in mailing).
By default, all internal users have this group. Mass mailing users also have
this group as writing mailings is about the same management level as writing
templates.
Mail Composer Mixin
-------------------
In comment mode, the template is rendered and then saved on the body field
so non-"Mail Template Editor" users can load email templates.
But in mass mode, the body of the template is saved and then rendered and
many things change the body (HTML sanitizer, web editor move inline CSS
properties, add / remove spaces...). So in this case, we can not know if
the user changed the body or not. That is why we put the body field in
readonly mode so, it is not modified by the web editor.
Jinja code detection
--------------------
To detect dynamic Jinja content, we compile the template, and we browse the
AST. If we do not have a single "Template Data" node, we assume that the
template is dynamic.
When we detect the template as static, we do not render it. That way we
avoid unnecessary rendering.
Code cleaning
-------------
Move Jinja import into tools so that it is outside of mail framework code.
Task-2187263
closesodoo/odoo#75840
Related: odoo/enterprise#20547
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit fixes a behavior when we send a batch of mailings
with no recipients.
When there is no recipients passed down, each mailing should
use it's own recipients and not the recipients of the first mailing.
closesodoo/odoo#75652
X-original-commit: 88d74fde5ce1ec70a88679429fda02180ce7fa81
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
BEFORE THIS COMMIT
When creating a mailing.mailing from "Create a mailing", the form can contain
a mailing.list field. This is a m2m and one can create and edit lists from
there. However, when using create and edit, the default creation form contained
a few smart buttons that can make the user exit the view. This does not have
much sense for a mailing list being created, and we want the user to stay in
the mailing.mailing being created.
AFTER THIS COMMIT
The view mailing_list_view_form_simplified is used when using create and edit
from there instead of default form one. It does not include any misleading stat
buttons anymore.
The footer including discard and close buttons is removed and is added to a new
primary inheriting view mailing_list_view_form_simplified_footer, used instead
of the previous one in the mailing.list creation form in kanban view, keeping
the previous behaviour and clarifying structure.
Since the field is a many2many in this case, we want the user to be able to save
and create / save and new / discard. This was not the case before, removing the
footer will result in using the default one for m2m. That way, all these actions
will be available as well and work as expected.
--- Links ---
Task-Id - 2605436
COM PR - odoo/odoo#74772
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Improve user experience of report model build on mailing traces.
SPECIFICATIONS
Add scheduled count to reporting. Indeed we have number of sent and delivered
traces but it lacks count of scheduled. Some traces are not sent for example
when email or sms is missing or obviously wrong. Those are currently not
counted in reporting, this is fixed.
Views are also improved to add relevant metrics and measures. Notably add
a list view on report model, allowing to see some metrics at a glance. Improve
SMS related views, hiding opened / replied metrics as we do not track them
currently in SMS.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
PURPOSE
Improve user experience by correctly contextualizing trace display when coming
from a mailing.
SPECIFICATIONS
Display relevant fields, hide other one (sms number when coming from a mail
mailing, email when coming from an sms marketing). Set some technical fields
as optional (message ID, status update). Use badge for status. Allow to open
recipient document directly from list view.
Improve wording (mail -> email). Reorder form view to try to have less noise
by hiding void fields and replacing the status bar (not clickable and any not
a business flow) by a classic field.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Purpose of this commit is to keep blacklist and optout lists computation
at mailing level and correctly call it in composer. This allow to have
a clearer and more readable code as well as more robust.
Currently it is done by adding this information in context before invoking
the mail composer. It is now correctly done in composer: if a mailing is
linked to the composer, it calls both blacklist and optout lists methods.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
RATIONALE
Prepare code cleaning and optimization in mail, mass_mailing and SMS by
cleaning models for readability and code complexity and footprint reduction.
SPECIFICATIONS
Purpose is to prepare future changes by easing its grep. Notification is too
much heavily used through the codebase and finding it was quite hard among
other noise.
Rename ``notification`` field to ``is_notification``.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Upgrade PR odoo/upgrade#1907
RATIONALE
Currently most of mail related failure types are computed in mass mailing.
This is mainly due to historical reasons. We could move some of this
computation directly at mail level and store failure information directly
in mail.mail records.
SPECIFICATIONS
Overall purpose is to get near SMS implementation where base composer prepare
more advanced pre computation: blacklist, optout, seen list.
Detect and store failure types directly on mail.mail: blacklist, optout,
duplicates, missing email, wrong email, ...
State computation is moved from mass mailing to mail. It is also improved as
currently everything is based on "first recipient found". This is globally
valid for mass mailing who uses default recipients (customer). However when
dealing with generic mailing this is not true anymore.
We choose to store and update status on mail.mail records only when having
a single recipient. When several recipients are defined on a given mail.mail
we cannot really decide a status prior to sending it and skip this computation.
Mass mailing override now uses information from mail.mail to update its linked
traces as computation is now delegated to base composer model.
LINKS
Task ID-2377974
Community PR odoo#61467
Enterprise PR odoo/enterprise#14633
Upgrade PR odoo/upgrade#1907
PURPOSE
Clean mailing code and ease understanding by replacing some old selection
keys by new ones better highlighting their use and aligned with other keys
used notably in mass mailing or SMS.
SPECIFICATIONS
Use shorted and mail-related keys. Indeed we already have sms_ and sn_ for
sms and snailmail related failure type. We therefore update failure_type for
mail as
* "UNKNOWN" -> "unknown", a generic unknown of uncategorized error;
* "RECIPIENT" -> "mail_email_missing", indicates email address is
invalid;
* "SMTP" -> "mail_smtp", connection issue;
"BOUNCE" key is never used and removed. Actually we use a bounce state for
bounced emails / traces so this key has no use.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Upgrade PR odoo/upgrade#1907
PURPOSE
Improve modeling and performances of mass mailing by manually updating trace
status instead of using complex computed fields and lessening fields usage.
Remove some fields and keep only relevant metrics to simplify and clean trace
model.
SPECIFICATIONS
In this commit we clean the way trace state is managed. Currently it is a
computed field based on several datetime fields. However this generates a
lot of noise in the table as well as unnecessary computation
* there are several columns (one for each state) storing datetime at
which status was reached. Generally only 2 or 3 contain relevant
information;
* state could be set in code directly to avoid a computed field based on
many triggers;
* recomputing it each time a date changes is not necessarily necessary;
* state value can always be updated manually as this is main done through
some automated server update (mailgateway, link clicks, ...);
As trace states and its triggers should not be updated manually it is better
to synchronize it in code flow. When there is an exception or update done
through sending or gateway status is updated as well accordingly. Various
datetime fields are also updated at the same time. In order to align with
notification model mail and sms trace status are updated to a classic field.
Only last status update is now kept as there is no need to store the entire
history of status change.
We keep only a datetime for relevant metrics: open, reply and click. Other
datetime bring no real value. Knowing when a trace was in error or bounced
is not necessary. Indeed exception generally indicates a server issue (at
sending), cancel indicates a data issue (at sending) and bounce depends on
customer email server.
Status update is removed as using write_date is sufficient. Once created
traces are updated only when an external event occurs (opened, replied, ...).
It allows to simplify trace model.
We also rename ignored field into canceled to match naming use through mail
and sms.
QUERY COUNTERS
This change has some positive update on query counters when sending mailings
as traces have less unnecessary status update compared to priori this change.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Upgrade PR odoo/upgrade#1907
RATIONALE
Currently there are differences between mail and sms error management
especially when sending them in batch (mass mode). Moreover cancel
(ignored) and error (exception) states meaning is not clear. Finally
some failure types management between mail and sms can be cleaned.
SPECIFICATIONS
Meaning of ignored / error we want to enforce now is
* error: there was something wrong at sending and user has an action to
perform, i.e. server failed -> check its logs;
* canceled: invalid recipients due to contact information or mailing
configuration (blacklist, opt out, void or invalid email or phone number).
In indicates issues linked to records themselves;
In this task we also add failure information granularity on mailing traces
linked to email like what is done currently on SMS. This can be related to
mailing (blacklist, optout, duplicates) or related to recipient (no recipient,
incorrectly formatted).
We also correctly distinguish optout from blacklist when sending SMS.
SPECIFIC USE CASES
* recipient without email / number: mail / sms is set as canceled, trace is
ignored;
* recipient with invalid email (no @) / number (formatting impossible):
mail / sms is set as canceled, trace is ignored;
-> we now distinguish when possible a void email from a wrong email using
a newly-added selection key (mail_email_missing);
* recipient with email / number blacklisted: mail / sms is canceled, trace
is ignored;
* recipient with email / number that optouted from mailing: mail / sms is
canceled, trace is ignored;
* recipient with email that bounces: mail is sent and will be set as bounce
when receiving bounce in gateway; trace follow same path;
* recipient with number that bounces: not supported as currently no support
of bounce through IAP;
* mail server error, IAP error: mail / sms is set as exception / error,
trace is set in exception;
This means we introduce new failure types on mailing.trace model to reflect
those failure types
* ``mail_missing``: missing email (different from wrong value);
* ``mail_bl``: blacklisted;
* ``mail_optout``: optouted;
* ``mail_dup``: duplicated email skipped during mass email send;
We introduce ``sms_optout`` on SMS and trace models as it was merged with
blacklist previously. Now both errors are distinguished.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Upgrade PR odoo/upgrade#1907
In this commit some reorganization is performed within mail compose message
code. Purpose is to reorder a bit methods by main usage: onchange, CRUD,
actions, values generation with rendering and template management.
Some renaming is performed on action methods, notably send_mail that has some
impact on sub-addons. Finally we also set onchange and sub-onchange methods
private.
No functional change should be implied by this commit.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
In the 'mass_mailing' module, the action helper has an absolute position
and will be placed relatively to the top left corner of the form sheet
With this configuration, the element can sometimes be placed off the
notebook page. It can occur when the list of recipients placed above the
notebook page contains a lot of elements.
To fix the issue, we will wrap the content of the notebook page in a
`div` having the `position-relative` class. The content helper will then
be placed relatively to that element which prevents the overflow.
task-2614456
closesodoo/odoo#75149
X-original-commit: 5d34828f5e25bb7c28c226c4226c1062138721c7
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Julien Banken