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>
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
This commit improves the form view of 'Mailing List Contacts'. It will:
- Add a color picker on the tag ('tag_ids').
- Make the bouncing counter ('message_bounce') unmodifiable.
- Make the creation date ('create_date') and the bouncing counter
('message_bounce') invisible when the user creates a new record.
task-2611112
closesodoo/odoo#74440
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When editing the bottom of a long e-mail, you can't see the top of the
sidebar's contents anymore. This addresses that problem by dynamically
repositioning the sidebar on scroll.
Task-2545445
closes#71511
Mass mailing form view currently has a scrollbar for the contents of the
editor, one for the form view itself, and one for the sidebar. In
consequence we can sometimes end up with three scrollbars side by side,
which is ugly and confusing.
This ensures the height of the iframe is always that of its contents so
there is no need for a scrollbar.
When inserting a new snippet we want to autoscroll to that snippet. That
is a complicated situation because the element we want to scroll is not
in the same document as the element we want to scroll _to_.
To address that situation, a new option is added to `scrollTo` so we can
pass it the element to scroll. It can then check if we are in the
aforementioned situation, in which case it can correct the scrolling and
apply it to the right element.
We use that option in mass_mailing to prevent the bug.
Task-2545445
closes#71511
Currently, editing a mail feels a little claustrophobic because of the
boxes within boxes within boxes design. This commit removes the chatter
and the sheet from the form view so the mail editor can take up more
horizontal space. The chatter is then moved into one of the notebook's
tabs.
Task-2545445
closes#71511
In order to limit encoding decoding, the _render method returns a
unicode string in the markup safe object instead of a MarkupSafeBytes
closesodoo/odoo#68299
Related: odoo/upgrade#2454
Related: odoo/enterprise#17270
Signed-off-by: Antony Lesuisse (al) <al@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>
Define `data-hotkey` on most used action buttons.
For the modals, the following keys are dedicated for "special"
actions:
- Alt+G: add
- Alt+V: save
- Alt+Z: cancel
closesodoo/odoo#73275
Taskid: 2588233
Related: odoo/enterprise#19464
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Requires markup every markup-using tip content as Markup. Would be a
nice occasion to migrate everything to a markup-safe markdown I think,
especially if we could migrate the translations so we don't lose them.
Add HTML fields support to kanban view (currently bespoke but maybe it
should be done via `format`), and remove t-raw for HTML fields there.
Also just strip some t-raws which were completely unnecessary to start with
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>
Purpose
=======
Remove the "email_send" field on the <mail.channel> (mass_mailing named
on the JS side).
This feature will be introduced with a new model (<mail.group>) in a
new module in the next commit.
Remove the email notification support on the channel, so now the mail
channels work only by chat.
Remove the "subject" on the Discuss side because this was used only on
"email" channel.
Technical
=========
In the mail channel model we can drop the usage of the blacklist as well
as the usage of the "email_to" field. Those two features were mainly
used for mailing list and have no utility for "chat like" channel.
Links
=====
Task-2510267
See odoo/odoo/pull/71599
See odoo/enterprise/pull/19296
See odoo/upgrade/pull/2600
This branch adds request.redirect on all requests.
In case of a front end request, we do an url_for to the location.
We removed redirect_with_hash that was only for retro compatibility
local_redirect has been renamed to redirect_query, and param keep_hash has been
removed and moved.
Default code for redirect is 303 now instead of 302.
Now redirect and redirect_query make local redirect by default, you need to
pass local=False to make external redirect.
All werkeug.utils.redirect has been replaced by request.redirect.
Http.redirect now use an http.Response type, and it become easy to add an
override like 'set_cookies' e.g.
Dispatch of a website.page return an http.response too, so we first need to
check if it is a cached version before to check if it is an Odoo Response.
Migrate your code:
http.redirect -> request.redirect(location, code, local)
http.local_redirect -> request.redirect_query(location, query, code, local)
http.redirect_with_hash -> request.redirect
Courtesy of odony for help and review ;)
closesodoo/odoo#72599
Signed-off-by: Jérémy Kersten (jke) <jke@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>
Solve SCSS compilation issues due to 'webclient.scss' that was initially
added in b3e7fd040b.
The fine is now unnecessary and it's actually causing the editor to
behave incorrectly.
closesodoo/odoo#72678
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*: tools
The ImageOptimizer option can now set shapes on images to use those
shapes as clip path and background. It uses a flexible path so that the
shape will always fit the image proportionally. We also added an html
file alongside a javascript file to semi-convert the shape from
illustrator into a usable shape for this usecase (the clip path must
have values between one and zero therefore we must do some computation
before the shape is ready to use).
Thanks to Samuel for this specific shape-converter tool and other
technical points about svgs and clip-paths.
Thanks to Mehdi for remaining development post-testing and post-reviews
and for the many fixes.
Thanks to Brieuc for the actual shape SVG files.
Part of https://github.com/odoo/odoo/pull/69179
task-2327045
closesodoo/odoo#69179
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: xO-Tx <mou@odoo.com>
Co-authored-by: Brieuc-brd <brd@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
This commit adapts the community codebase to the rewriting of the
/web application in owl.
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
To prepare the rewriting of the webclient in owl, we move all
current js files of web in a legacy/ folder. This folder will
eventually be removed, as soon as each file it contains will be
converted to owl and moved to the proper place in the new file
structure.
Before this commit, when editing a mass_mailing template, on save,
the editor would not tell the snippet menu to perform a cleanForSave
which it should normally do for the option to properly prepare to save.
Bug discovered while working on task-2327045
Ideally, would need to be backported but requires a different fix in the
old editor.
closesodoo/odoo#72346
X-original-commit: 639b6a55586107bd3d855d322c1102df101eb079
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.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>
HTML fields used to have a toggle button for a "code view" (which came
from the Summernote library), in debug mode. This allowed the advanced
user to edit content with jinja conditions. This was lost with the new
editor but reintroduced for Mass Mailing. As it turns out it was needed
elsewhere so this makes the code view available as a node option, and
already activates it for mail templates.
To activate the code view in an html field:
```xml
<field type="html" options="'codeview': True"/>
```
Task: 2561300
closes#71860closesodoo/odoo#71891
X-original-commit: 0f9684677676b563a0ff2712e42cea24a2ef27bb
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Currently, to identify records based on state, in most of the list views we
use 'badge' widget on 'state' fields which can be decorated as needed.
However, for the list views, best approach would be to also add list
decoration along with 'badge' widget so that the whole line is colored
and it's easy for user to 'scan' the information
This commit improves the behavior adding decorations to several list-views.
To check the list of changes, kindly see the task specification
Apart from that, this commit also improves label of the module state from
'Not Installed' to 'Uninstalled'.
TaskID-2527119
closesodoo/odoo#71367
Related: odoo/enterprise#18587
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The "o_mail_snippet_general" class implies a background color but when
coloring the snippet that color was applied to its parent. This ensures
that the color is applied to .o_mail_snippet_general instead.
closesodoo/odoo#71500
Related: odoo/enterprise#18619
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Colorpicker snippets target <td> elements while these sometimes contain
a <div> which is background-colored in css. In consequence, when using
the colorpicker to change the background color of the snippet, the
colored <div> came in front of the element of which we tried to change
the color. This ensures the snippets target the <div> instead when the
<td> itself is marked as non-colorable via the "o_mail_no_colorpicker"
class, as this is then in fact the element we want to color.
Enterprise themes need to be adapted to this new behavior.
Mass Mailing needs to extend the registry of wysiwyg snippets but
couldn't do so because they didn't live in the same window. This moves
the mass mailing snippets to the top window.
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>
std-odoo