*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>
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
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
Purpose of this commit is to clean field definitions by
* doing compute in batch: especially when the loop can be reduced to a single
computation / batch assignment (based on groups or config parameter for
example);
* remove default when having a compute as computes should completely define
the field value at any time;
Some side dish code cleaning is performed at the same time: unnecessary
import or dead code removal.
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>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@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
Propagate reply_to radio keys (update and new) to mass mailing in order to have
a coherent naming (was thread and email). This naming is also coherent with
gateway naming (message_update and message_new).
LINKS
Task ID-2117639
COM PR odoo/odoo#40931
ENT PR odoo/enterprise#17941
UPG PR odoo/upgrade#2419
Including demo data this time
closesodoo/odoo#58862
X-original-commit: 575abde110acb3d12b25f177a863374becef0894
Related: odoo/enterprise#13705
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
Purpose
=======
Provide a follow-up/overview of the Mailing 24 hours after its been sent.
Specifications
==============
Send an email to the responsible of the mailing 24 hours the last email
of the mass mailing.
During the link trackers creation, extract the button label if exists
(so we can display them in the statistics email).
Technical remarks
=================
The statistics email is sent to the responsible of each mailing in the
CRON of mass mailing.
Task-2227411
closesodoo/odoo#49836
Related: odoo/upgrade#1094
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Clarify the use case in which a specified email address is set as replies may
not be traceable. Make the %Click KPIs visible for Emails as well. Allow users
to report on the links that have (or not) been clicked from their
mailing.
SPECIFICATIONS
Add an info text for the "specified email address" option in the "reply to"
field. If target model does not accept incoming emails warn the user it is
likely to fail.
Number of emails/sms sent is now display as clickable text instead of stat
button and clicked stat button is now also visible in mass_mailing.
Task ID: 2202495
PR #48339
* Code cleanup
* Avoid a safe evaluation of the field value when loading those records.
closesodoo/odoo#44883
Related: odoo/enterprise#8283
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Prior to this commit, two fields were used for lead and opportunities
count.
As both of these fields were set with the same values and only existed
for labelling purposes, this commit replaces them by a single field
and handles the the labels in the xml.
This commit also improves the way lead count is computed by using
a read_group instead of a search in a loop.
LINKS:
closes odoo/odoo#38707
Taskid: 2086863
Pr: #38707
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Without demo data, for the odoo-master transifex project
closesodoo/odoo#41935
X-original-commit: dab7670b73506fb3a835695ee3bd735e0c5e5c2b
Related: odoo/enterprise#7287
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
- correct some errors in the text field
- transform the utm.tag.view.form view to utm.tag.view.tree view to allow direct tag editing
closesodoo/odoo#37008
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
SMS are a powerful marketing tool. For instance it is perfect to announce a
sale or to communicate a coupon code, to welcome a new customer in a fidelity
program, ...
Purpose of this task is to integrate SMS sending in batch in mass mailing. It
will use same mailing objects but sending SMS instead of emails. Some metrics
and flows will have to be slightly updated at the same time.
SPECIFICATIONS
Prepare mass mailing module to addition of mass_mailing_sms.
Mailing model: mailing type
* add a mailing_type selection field;
* mass mailing contains only 'mail';
* synchronize medium accordingly;
* update actions of mass mailing application to add a domain on mailing
type being 'mail';
Mailing contact
* remove is_email_valid field as its purpose is achieved by email_normalized
field coming from address mixin (added by blacklist management);
Mailing contact subscription
* clean a bit fields and views as this should stay a technical model;
Trace model and report: trace type
* add a trace_type selection field;
* mass mailing contains only 'mail';
Various
* clean some bits of code in views, remove old code bits;
* add anchors to ease view inheritance to be able to customize views for
SMS mailings;
* ensure all views in mass mailing filter content on mail type (mailing
and traces being type mail only);
* rename some methods to be more updated with current guidelines, notably
main action methods;
LINKS
Task 1997464
PR #34424
Original SMS addition: Task 1922163 (4287481)
PURPOSE
This commit removes the mass_mailing.campaign model. Instead of having a fully
fledged model, we will simply inherit utm.campaign. We will also add relevant
statistics on utm campaign model in order to use it in various applications.
SPECIFICATIONS
This commit removes the mass_mailing.campaign model. Instead of having a fully
fledged model, we will simply inherit utm.campaign. This change implies that
mass_mailing.tag and mass_mailing.stage have to move to the utm model along
their associated views/data.
These changes were made so that campaigns could be used in the future
by social, mass_mailing and mass_sms and available in the same view
This commit also removes the source_id and the medium_id
fields on the campaign.
This commit also moves the unique_ab_testing field from the mass_mailing_campaign
to the mass_mailing model
Task ID: 2002029
PR: #34015
PURPOSE
Mass mailing is currently a bit messy. As SMS will be added as a way to notify
people in mass through SMS let us take this opportunity to somehow clean this
application: organization, light code cleaning, model renaming.
SPECIFICATIONS
Rename mail.mass_mailing model to mailing.mailing. Rationale :
* mailing is now a prefix for mass mailing models;
* mailing.mailing is easier to read / find / understand;
Note that mail.mass_mailing.campaign is not updated as it is likely to be
removed soon and replaced by simple utm.campaign model.
MIGRATION
mail.mass_mailing model -> mailing.mailing
mail_mass_mailing table -> mailing_mailing
LINKS
Task ID 2037906
Preparing task ID 1997464 (SMS addition in mass mailing)
PR #34938
Martin Trigaux