When using a template with inline placeholders in the body, the Test
button will replace the placeholders, but they will remain in the final
body when the mass mailing is sent for real.
This commit fixes this issue by using the correct rendering engine for
the Test button too.
OPW-2819032
OPW-2828461
closesodoo/odoo#89346
X-original-commit: b0dcd2fa35d949dd722f1bc70401ceeb7f5d8231
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Paul Morelle <pmo@odoo.com>
Even if ORM normally filters them out, no need to specify .id in domains.
This leads to better and easier to read queries / domains.
Task-2816580
closesodoo/odoo#85648
Related: odoo/enterprise#24911
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Filter the mailing templates based on the model defined on the mailing,
so the user will see the most appropriate templates.
Task-2593231
Part-of: odoo/odoo#79174
Purpose
=======
Allow users to re-use a design they made in a previous mailing.
Specifications
==============
Add a duplicate button when the mailing has been sent (so the users
can easily duplicate an existing mailing to re-use the template).
Allow the user to add a mailing to the favorites. When we open the web
editor for the first time, show the email bodies of the favorite
mailings. When the users click on them, load the HTML like we do for
the themes.
Task-2593231
Part-of: odoo/odoo#79174
Purpose
=======
Open the standard mailing list form view when creating a mailing list
from the Kanban view because it had no use and was a bit confusing.
Rename the field "Is Public" to "Show In Preference" to describe a bit
better the usage from a functional POV.
Task-2593231
Part-of: odoo/odoo#79174
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
Currently when user starts using the app and tries to 'import records' from
'Mailing List Contacts', there is no templates available to assist the user.
This commit adds import template for mailing contacts to assist the users
in importing records.
taskID-2763984
closesodoo/odoo#84804
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Ensure that the names of the UTMs models (campaign, medium and source)
are unique.
If not, generate automatically an unique name.
The name field is no more translatable; it makes no sense to translate
a technical which will be added in the URL, and can even cause issues
(the UTM record is not recognized because of the translation).
For the campaign, we keep a "translatable" name which is called
"title".
For the UTM source, use a mixin to generate automatically the name of
the source based on the content (_rec_name) of the record. So we remove
the override of create / write / copy in the different models and
ensure consistency between those models.
Task-2245823
closesodoo/odoo#60501
Related: odoo/enterprise#21882
Related: odoo/upgrade#1863
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The function that converts inline images to urls returned the modified
html as a byte string. As a result, the Mail Debug tab showed a
hexadecimal string rather than rendered html. This makes sure the string
is encoded in unicode instead, so the format of the string coming out of
the function is the same as it was coming in.
closesodoo/odoo#84942
X-original-commit: b4094ed004a59512d70913f9cc41de8df894296e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Purpose
=======
Allows the user to easily import mailing contacts.
Specification
=============
Add a button "import" on the top of the mailing contact list view. This
button open the wizard <mailing.contact.import>.
So the user can select the mailing list and import his contacts with a
text field, one line for each contact.
Task-2703521
closesodoo/odoo#82333
Related: odoo/enterprise#23263
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Bug
===
Since 576556d846 we merged the list
coming from the context key default_list_ids and the list given by the
user in subscription_list_ids. It worked well because the 2 fields
"list_ids" and "subscription_list_ids" were not in the same view at the
same time.
But if we want to create from the backend <mailing.contact> by giving
a value in "list_ids", the context key "default_list_ids" must be
ignored (like standard Odoo fields).
Task-2703521
Part-of: odoo/odoo#82333
Activities and mailing trace are linked to documents through a model and
a many2one reference field. The latter one is required but is implemented like
an integer field, meaning writing 0 is actually a valid value for 'required'.
In this commit we add a constraint to ensure we never update activities with
a void res_id value. Same for mailing traces. This allows to remove the
required attribute on fields to avoid having redundant sql constraints.
Source: internal feedback about activities with 0 as res_id
Task-2694133
Part-of: odoo/odoo#81292
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
Followup to #82105: turns out we kind-of forgot that records could be
updated with new attachment and the exact same issue could occur.
So with the same reasoning as the previous PR, re-attach attachments
to the current object when updating it.
closesodoo/odoo#83083
X-original-commit: 398070ec1b6ed7d6a8e7c0ab75d45b8a9ad0e0d0
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Attachments that are uploaded on a record that isn't saved yet are
created with res_id set to 0. In the case of attachments linked through
a m2m rather than the usual (res_model, res_id), it means they may not
be readable afer the creation of the record, except by their creator.
Re-attaching them to the mailing / template at the end of the create()
call fixes the ownership.
Fixes#81935closesodoo/odoo#82120
X-original-commit: 05fb705f2729ffdf07ab36accda20415a44e1aa6
Signed-off-by: Olivier Dony <odo@odoo.com>
Purpose
=======
Allow users with enough access rights to disable next-day report on
mass mailing lists. The option has been added in the mass mailing
settings and is enabled by default. Mass mailing reports can also be
disabled with a "Turn off mailing reports" button in the report email
itself. Reports are enabled and disabled for all responsible.
Task-2692211
closesodoo/odoo#82430
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*mass_mailing_crm, mass_mailing_sale
Currently, the Mailing stat buttons have a few problems.
The business reporting smart buttons send the user to a list of linked records,
which doesn't provide much value (e.g. what is the user supposed to do with a
list of 12345 leads?). They also show wrong values depending on access rights.
The Mailing KPI smart buttons lead to a blank screen if there's no data to show.
In this commit, we add/adapt all action helpers to help users understand what is
going on. For the business reporting smart buttons we instead send users to
relevant reporting actions, so they can make sense of the data we showed before.
The values of the business reporting smart buttons are now calculated as a super
user.
We also change some domains from the whole UTM Sale Domain to only using
Source ID, which simplifies computation while staying accurate.
task-2604515
closesodoo/odoo#76798
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Right now, in our mass mailing, marketing users refine the audience they are
going to reach with our beautiful domain selector/editor. The problem here
is that the criteria that 'filters' audience can be very common and might be
used in many mailings.
Such filters have to be re-created manually each time they are needed unless
one duplicates a sent mailing. Another possible workaround is to access this
form view while in debug mode so that one can copy and paste those domain
expressions. Unfortunately, none of those solutions are either ideal or
convenient. Especially during the onboarding where new users are not very
familiar with those notions yet.
This commit allow users to save filters on the mass mailings. That way
favorite filters can be re-used on the next mailing. For that, we added
a new model 'mailing.filter'. We do not use existing 'ir.filter' model as
its usage is not completely the same and as we do not want to bloat view
filters with filters created on the fly in marketing application. This new
model contains the following fields:
- name (given by user while saving the filter)
- mailing_domain
- mailing_model_id (m2o for the recipient model)
- mailing_model_name (technical name of recipient model)
Users can create the filters by setting domain and then hitting hollow star
icon next to 'Filter' m2o and saving it with the name they want. Same way
to delete the saved filter, user simply have to click the filled star icon
when filter is already set. This is done through a new widget that adds its
own behavior on top of m2o widget.
The saved filters can be also managed with a new menu named 'Favorite Filters'
under 'Configuration' menu of Email marketing.
Task-2092853
closesodoo/odoo#70859
Related: odoo/enterprise#21049
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Some stored mailing fields should use the real mailing_model_id many2one
field for triggers and not sub-fields of it. As those are not stored this
may lead to unwanted writes.
Followup of odoo/odoo#41877
Spotted during Task-2092853
Part-of: odoo/odoo#70859
Purpose
=======
Improve UI of mass_mailing module to give the user a clearer view of the
mailings they send, enabling A/B test by default since it is not invasive.
Specifications
==============
Remove border and padding around the chatter in mass mailing form view.
Add sum and average in mailing list view for KPIs
Change sort order from sent_date to calendar_date
Move user_id in form view
Set group_mass_mailing_campaign to True by default
Task-2679537
closesodoo/odoo#79213
Related: odoo/enterprise#22202
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
This commit consolidates UTM usage across all applications.
Global purpose is to avoid having undesired side-effects, such as unlinking an
utm.source/utm.medium/utm.campaign and at the same time cascading the deletion
to various records without noticing.
SPECS
ALLOW MORE PEOPLE TO CLEAN UTM RECORDS
Currently, not even the system administrator can delete utm.mediums and
utm.sources (he can only delete campaigns).
These were considered as "technical records", but allowing some cleanup is
a good idea since these records are often automatically generated and can
create a lot of unnecessary noise in the database.
That's why we now allow the following groups to delete all UTM records
(sources, mediums and campaigns):
- group_system
- group_mass_mailing_user
- group_social_manager (enterprise)
PREVENT DELETION
For some use cases, removing an utm.source/utm.medium/utm.campaign would
cascade delete the related record, which was unintended / hidden side effect.
These combinations were secured by preventing to unlink:
- mailing.mailing source_id field
Trying to delete the utm.source will throw an error message
- mailing.mailing medium_id field
Trying to delete the utm.medium will throw an error message
- hr.recruitment.source source_id field
Trying to delete the utm.source will throw an error message
ADDING CLEAN ERROR MESSAGES
When trying to delete an UTM record that is linked with ondelete="restrict", we
improved the error message to give a clear explication to the user, e.g:
"You can't delete these UTM sources as they are linked to the following
mailings in the Mass Mailing APP, and deleting the source would break the
statistics: Newsletter"
SPECIFY 'ondelete' strategy
For a lot of uses of sources/mediums/campaigns, the 'ondelete' strategy was not
specified, leading to the confusion of "is this really how we want to handle
this?".
A lot of ondelete="set null" have been added in various field definitions to
ensure that this is the desired and logical strategy we want for that
specific model.
PREVENT REMOVING HARDCODED UTM RECORDS
In some functional flows, UTM records are hardcoded using their direct
record reference.
This is notably the case for the recruitment process and its creation of
aliases, and for the Email / SMS Marketing flows.
As deleting them would break these flows, we prevent their deletion in a
"api.ondelete" method.
ENFORCE NEW RULES WITH TESTS
A lot of python tests have been added to make sure we enforce the decisions
taken here above.
LINKS
ENT PR odoo/enterprise#19048
Task-2459480
closesodoo/odoo#72239
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When mailings have no responsible, KPIs emails are broken as there is no
from and to on the mail. This leads to mails being invalid and set in
exception.
Moreover currently author and from / to of those D+1 emails are not coherent
as author is current user (generally odoobot as this is generated through
a cron) while from and to are based on mailing responsible.
In this commit we make statistics emails more coherent
* when a responsible is set on the mailing: author, from and to are linked
to the responsible;
* when there is no responsible, current user is set as it may be sent by
regular people;
* reply-to is set to company email as it is often the case with 'marketing'
emails;
Task-2686586 (Repair mailing statistics email)
X-original-commit: 95a21ca16f560cf4341c547f6bc909d3261acd1b
Part-of: odoo/odoo#79877
When there is an issue updating mailing state (concurrent access, or some other
error that may happen), mailing statistics emails may be sent in loop. As we
do not think timing is so important, we now use the email queue to send
statistics emails.
Task-2686586 (Repair mailing statistics)
X-original-commit: f78ac45c2eafc3cf6b213e1f1608e76e243bd8d2
Part-of: odoo/odoo#79877
Currently if someone replies to a mass mailing email, then performs a click on
tracked links, final trace status is set to opened. Indeed both reply and
click set the trace as opened, as replying or clicking imply opening the
mail.
Update is the following
* user replies -> set status to open, then set status to reply, and update
open_datetime and reply_datetime;
* user clicks -> set status to open, then update click_datetime;
In the end the trace is left as opened while it is replied, with a click
datetime attached to the trace. To avoid unnecessary status update, a trace
is set to opened only if it is not already opened or replied. Other statuses
should not override themselves.
Task-2692316
X-original-commit: ce88d364369c8b58256e8d93b7cb506a2c262a34
Part-of: odoo/odoo#79877
Recently some "de-t-rawify" [1] was done through Odoo. A change in digest
layout broke mailing statistics. Indeed mailing statistics are build on digest
main layout to re-use it. In mailing case a ``kpi_name`` value was missing when
rendering statistics columns, leading to a crash. This is now fixed in both
mailing and sms marketing.
In this commit we also add tests for statistics emails (D+1 KPIs) rendering
for both mail and SMS marketing mailings. Email details are also tested
in order to better highlight future changes and tweaks in email sending
linked to D+1 KPIs emails.
Task-2641394 (Digest emails sending improvement)
Task-2582128 (Digest onboarding and usage improvement)
Task-2686586 (Repair mailing statistics email)
[1] odoo/odoo@c56e8c9f5a
X-original-commit: c9905ceb3172d8e80e3aff4ae9bc925dcb6b6519
Part-of: odoo/odoo#79877
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>
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>
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>
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>
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
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
Purpose
=======
Now that we try to not spoof the FROM SMTP headers, we want to improve
the default mail FROM used in mailing. By default, it's the email of
the current user, but if no mail server is configured for it, we will
use the notification email instead and encapsulate the email of the
user in it.
e.g.:
Original: "Admin" < admin@odoo.com >
Final: "Admin (admin@odoo.com)" < notifications@odoo.com >
Show a warning message if the configured mail server can not be used
for the email from.
Task-2367946
odoo/odoo#61853odoo/upgrade#1903
PURPOSE
This commit aims to apply some cosmetic changes on the mass mailing
tree view to improve its usability.
SPECS
- New precedence order for the mass mailing views: With the kanban view,
mailings tend to pile up. When there are a lot of mailings, it can become
tricky to find a specific mailing given that the names of the mailing are
often generic and redondant (e.g. "Don't Miss Out", "Special Offer", ...)
For this reason, we will encourage people to use the list view by giving
the list view a higher precedence over the kanban view.
- Add progress bars for the delivered rate and the open rate (in the tree view).
- New column order for the tree view.
- Remove the unused and invisible field 'mailing_type' from the tree view.
- Set the fields 'mailing_model_id' and 'campaign_id' as optional.
- Minor decorator update.
LINKS
Task id: 2588188
closesodoo/odoo#73276
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
To reproduce the error:
1. Open Email marketing
2. Go to the calendar view
3. Click on a cell
Explanation:
The function 'default_get' defines an argument named 'field' that conflicts
with the 'field' variable imported from the default 'odoo' package. When
two identifiers conflict, Python will use the variable defined in the closest
enclosing scope.
When the 'default_get' function accesses the 'Datetime' attribute of 'field',
the function will raise an exception as the identifier 'field' will refer to
the argument of the function and the property 'Datetime' will not defined on
that variable.
To solve the issue, we will rename the argument of the function 'default_get'
to 'fields_list' so that it will no longer conflict with the imported variable
'fields'.
Links:
Task id: 2581357
closesodoo/odoo#72857
X-original-commit: a9f6f708d40d0ecafb4a903eb9ff810a6c959416
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Traces are always linked to documents as mailings are sent on
documents. Those fields should be required to ensure database
coherency.
Task ID-2525759
closesodoo/odoo#71786
Related: odoo/upgrade#2513
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
As the mailing.list model has his own custom merge method, this model should
not be candidate to activate the generic merge method comming from data_merge
module.
This change is done here to avoid creating a bridge module in enterprise
only to add this flag. We can consider that the flag is linked to the custom
merge method itself. If a model has a custom merge method, it should be marked
as 'having a custom merge method'.
Task ID: 2459416
Linked ENT PR: odoo/enterprise#17553
Currently ``mail.render.mixin`` offers rendering tools, some of them being
based on a ``model`` field. It allows to know which model to use to fetch
records on which we perform rendering. However this field is not defined at
mixin level but in inheriting models without being clearly implemented that
way (see ``mail.template`` or ``sms.template`` models).
In order to clean this mixin it is now defined at mixin level, using a
not stored computed field allowing to define how to find this model. Sub
models are updated accordingly.
Other cleaning is done in the render mixin
* rename ``_render_template_qweb`` to ``_render_template_qweb_view``
to indicate it works on views, not on raw qweb templates;
* extract some common available variables for rendering in a method then
called / upated for jinja and qweb views;
* correctly set same rendering context for jinja and qweb views rendering;
* allow to propagate an additional context from _render_field to sub
rendering methods;
* allow to propagate options through rendering methods (notably for escaping
or safe attributes in jinja);
* allow to specify engine used to render lang;
* clean or update some docstrings;
Some tests are also added, as render mixin lacks some more detailed test to
ensure various use cases will be correctly migrated to other engines like
QWeb.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
Prepares Task ID-27033 (QWeb in templates)
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
Co-Authored-By: Stéphane Debauche <std@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
PURPOSE
Remove hardcoded list of models on which mailing is possible. Indeed it is
not modular and not really smart with enterprise code not being reachable
in community.
SPECIFICATIONS
Replace hardcoded list of models on which mailing (both mail or sms) is
possible by a computed searchable field on ``ir.model`` based on a class
attribute.
It allows to cleanly define models having mass mailing capabilities and add
this attribute in bridge modules (when existing) or directly on base model
definition to avoid bridge modules.
In this commit we introduce a basic ``_mailing_enabled`` class attribute
activating mailing on model.
Mailing models may also have a ``_mailing_get_default_domain`` method allowing
to define a custom default domain when sending a marketing mailing on records
on this class.
Mailing models can now define a ``_mailing_get_opt_out_list(_sms)`` method
allowing to define custom behavior to fetch opt-outed records. Instead of
defining a model-based behavior on Mailing itself, it now calls the model
defined one. We still have two methods, one for mailing and one for SMS
opt out computation as it relies on different underlying models and fields.
LINKS
Task ID-2431217
COM PR odoo/odoo#67322
ENT PR odoo/enterprise#16876
UPG PR odoo/upgrade#2236
There is a missing depends on subscription_ids fields, meaning it is not
correctly refreshed when contacts are updated. When dealing with m2m using
the o2m model as relational table, depends have to be specified on field
itself to allow recomputing the fields.
Task ID-2431217
COM PR odoo/odoo#71140
X-Original-Commit odoo/odoo@11ffeddf23
X-original-commit: 37bad522bcaf9a6db2f676286fb9ceb1a188dcab
Having those fields as translatable lead people to think those will be
translated into recipient's language. This is incorrect as translations
in Odoo are based on current user, not about any recipient who would
see the field value.
In this commit we therefore remove translation capabilities for
subject and preview. Indeed mailings currently offer no multi languages
support. Instead people should create separate mailings targetting
some specific recipients, based on lang or country for example.
Task ID-2535807
closesodoo/odoo#71093
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Victor Feyens