These changes are made as a result of simplifying attrs and 'states' in
views. However, they should have remained in a separate commit. When
applying the script making the xml changes (used later for the migration
script), the script checked the definition of the python fields in order
to convert the information into a python expression. Therefore, this
commit is not applied when the script is applied to xml changes.
During this attribute deletion pre-existing errors were found. Part of
the code was using the boolean values of 'states' and another part of
the code was not. The behavior could therefore be different (in cases
where readonly on the field had the same value as the ballan in
'states').
Following the deletion of 'states' and without the application of the
view migration, the js tests (tower) were no longer functional. Tests
using the Form view suffered the same effect. There are few tests that
had to be adapted, including two tests in business accounting (updated
by the accounting team). A test for column_invisible did not work. Test
checking if the test system triggers an error if we try to write on an
invisible field. It turns out that Form was testing on the value of
invisible but not taking into account if the column was invisible. The
test system fix is applied separately because there were a lot of tests
that were incorrect.
Part-of: odoo/odoo#104741
Base64 img src were converted to inline images but background images
were omitted. This commit fixes that.
opw-3374767
closesodoo/odoo#129645
X-original-commit: a10d1d305696f7ece38e7d3446c067338c411ea2
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit
- When we were creating an alternative version in the SMS app for A/B
testing, we were not able to see different options like select
winner, compare version, etc in it because of ab_testing_mailings_count
was counting only records with type equal to mail, in method
_compute_mailing_mail_count. So, count will never increase
and those buttons will never be visible.
- We were not able to sent the mail manually in auto mode.
- We were able to see the 'Send winner Now' and 'Send this as Winner'
buttons even if no a/b test mail were send.
So, with this commit
- We have added the ab_testing_sms_count compute field in utm.campaign
and ab_testing_sms_count related field in mailing.mailing to deal
with the above problem.
- The auto mode can now send a winner manually.
- We introduce a new compute field is_ab_test_sent for computing
whether the any sibling mails of a/b testing are sent or not,
depending on that we hide / show buttons.
TaskId-2713198
Part-of: odoo/odoo#88997
Base64 images get converted to attachments. However, if they are in a
mso comment, they were not converted.
X-original-commit: 2fa0694227a7beb6a000c2e8219fdd8c073cf348
Part-of: odoo/odoo#124465
Prior to this fix, elements with background images were converted to
images via the html2canvas library. This made them work in Outlook at
the cost of several tradeoffs:
- the process was slow and asynchronous
- there could be no interactivity (links, buttons, etc.) in the
converted element
- responsive behavior was wonky: if only a slice of the image was shown
when it was converted (due to background-size cover behavior), the
rest was lost so if more width was needed in mobile, we would be
zooming on that slice, making it sometimes irrelevant and pixelated
This replaces all that with a conversion to VML, which is a vector
format supported by Outlook. This conversion is done only for Outlook,
which means that all other clients are getting the original background
element again.
There is a way to keep the background-size cover behavior in VML, using
the "aspect" attribute with value "atleast" but this only works on
v-fill elements and sadly putting the image on a v-fill element bugs in
Windows Mail (which is the default mail client on Windows 10 and 11) and
this client can't be singled out of mso conditionals. To get around this
issue, since this is only for desktop clients, we assume the width of
the screen to be large and mimick the cover behavior by cropping the
image to the target size. This allows us to put the image on the v-image
element and have proper rendering in Outlook and Windows Mail on
desktop.
Note:
When retrieving the image by URL in Python in order to crop it, we need
to ensure we have an absolute path. This is done - perhaps seemingly
naively - by checking if the URL contains '//'. Here's the reasoning
behind that choice. To check if a URL is absolute, we could use
`urllib.parse.urlparse` and check if it has a scheme but that would lead
to `www.odoo.com/path` being considered relative (and thus we'd add a
host to the URL even though there's already one). Instead, we could
check it it has a netloc but that would lead to the same issue since the
documentation of `urlparse` says:
> Following the syntax specifications in
[RFC 1808](https://datatracker.ietf.org/doc/html/rfc1808.html), urlparse
recognizes a netloc only if it is properly introduced by ‘//’.
Still, it would be more technically correct since `//some/path` would be
considered absolute (which it should be since it resolves to
`<current_scheme>//some/path`).
Base on that documentation, it seems that simply checking if the URL
contains '//' is pretty much equivalent to checking if it has a scheme,
with the double advantage that it's simpler and that it works for
`//some/path` as well. However, note that it doesn't solve the issue of
`www.odoo.com/path`.
In summary, here are the results with the current method:
```
http://www.odoo.com/path -> http://www.google.com/path // OK
some/path -> http://localhost:8069/some/path // OK
/some/path -> http://localhost:8069/some/path // OK
//some/path -> //some/path // OK
www.odoo.com/path -> http://localhost:8069/www.google.com/path // WRONG
```
X-original-commit: 9561ba31917024825705c876442139405e7a7957
Part-of: odoo/odoo#124465
When using message_post, the body format must be explicitly specified.
If html is expected, a Markup object should be used.
If text is given, the content will be escaped.
Before this PR:
message_post was unaware if the content of a message was HTML or
text. This lead to multiple situation where the content was
incorrectly considered as HTML and led to display errors.
In
self.message_post(body="Hello %s!" % self.name)
if the name contained HTML, it would be evaluated.
In
self.message_post(body="Contact Raoul <raoul@caramail.be>")
the email would not be displayed as considered as unknown HTML and
discarded by the sanitizer
Now each call must explict the type of content.
Use the escape() helper to properly combine Markup and translations.
It would also be acceptable to use Markup() to wrap a static
translation but escape is better as one can not guarantee the content
of a translation.
closesodoo/odoo#111850
Related: odoo/documentation#3612
Related: odoo/enterprise#36728
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The digest currently includes a CSS variable for the company's
secondary color, but Outlook does not support it.
This commit replaces the CSS variable in the digest with the QWEB
variable. Apart from that, if the secondary colour of the company
is available, it sets it into the colour property header of the
"mass_mailing_kpi_link_trackers" in email marketing and revert the
changes in commit[1] because border-start/end is an invalid property in CSS.
commit[1] - odoo-dev@1fcd098#diff-faee7192e5f6cf07658d2ceae16380c4b5d54035ecfb9bb4848608db3f429c69L263
tast-2717426
Part-of: odoo/odoo#89549
Rewords and fix the typos in the mailing.mailing model notes.
Task-3240405
closesodoo/odoo#116756
X-original-commit: 156b901292b01e6bb6cd430caade3ae95742782b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When the user schedules a datetime for the emailing campaign, it creates
a ir.cron.trigger entry that should run the Mail Marketing: Process queue.
This fix tries to take this into account to calculate a next_departure
datetime closer to the true moment job will be run.
When the schedule datetime is between now() and the next call datetime
for the cron job (nextcall field), current logic will always chose
nextcall given the use of max(). This can be confusing for the end-user
as the information banner in the form view will indicate the nextcall date,
which in some cases can be way farther in the futur.
While a ir.cron.trigger is not a 100% guarantee that the cron job will
run at that specific time, it will give better feedback to the user for
when he should expected his mailing campaign to be send out.
Main changes:
simplified logic in _compute_next_departure to take into account
the implicit creation of cron.triggers (methods action_launch and
action_schedule)
added test_mailing_next_departure to simulate "Send", "Cancel" and
"Schedule Date" buttons on mass_mailing form view. Check ir.cron.trigger
model for presence of triggers for cron job "Mail Marketing: Process queue"
and assert if cron.trigger was created as expected
opw-3137819
original commit b98494d
some trailing whitespace got linted from commit 4cebf5
closesodoo/odoo#115068
X-original-commit: f82dec9e6433dc027391978420237efaa1d0be7d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The purpose of this key was to force the form view to be in edit
mode directly when opening a record, in specific actions. This is
now automatically the case since form views are always in edit
mode. This commit thus removes the support of the key, and removes
all occurrences where it was set in the codebase.
Part of task 3179751
closesodoo/odoo#115172
Related: odoo/enterprise#38130
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
A/B testing was used in the past to create mutually-exclusive mailings.
Since then a 100% limit for the recipients of an A/B campaign.
As there is no technical reason for this limit and not having it allows
for a special usecase, it is replaced here with a text warning.
The usecase in question being that as the domain of the different
mailings composing a campaign may be different, users may want to
take advantage of the fact that only 1 email will be sent to each
address to avoid sending 2 mailings when only one or the other should
be sent. Consequently users may want to use 100% of the domain on
every mailing in their campaign.
As the ab_testing_total_pc is only used for that purpose the field
is removed. 'total' field is not always accurate and is unused so
it is also cleaned up.
task-3008627
closesodoo/odoo#105639
Related: odoo/upgrade#4257
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Since Python 3.11, sampling from a set deprecated, the population must
be a sequence.
This commit applies the suggested fix.
Also, the filtering of the deprecation warning about sampling from set
can be disabled when the python version is not 3.9. This warning was
wrongly triggered since 3.9 because recordsets are bot a sequence and a
set.
This was fixed in python 3.10, see https://bugs.python.org/issue42470closesodoo/odoo#112450
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
The percentage used for A/B test was applied even when
A/B testing was disabled. As that value is 10% by default
the 'total' was innacurate by 90% for most mailings.
task - 3008627
closesodoo/odoo#110677
X-original-commit: eb2271330e7759400dad155b72208cf7677e175e
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Correctly update 'auto_delete' field
* add missing update in onchange, to either take value from template, either
fallback on default_get values as other fields;
* in comment mode, actual value for 'auto_delete' is True by default. Composer
value was not used and bypassed by a context value being True by default.
Context key support is removed, correctly replaced by the composer field
value itself;
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Use the new 'res_domain_user_id' field to use in combination to 'res_domain'
on composer to delegate res_ids computation to the composer instead of relying
on res_ids or active_ids. Records to mail are not stored inside a domain.
Set auto_delete values directly when invoking the composer instead of hacking
the generate mail values. That way we delegate more to the composer itself.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Support a real res_ids field on mail.compose.message model. Instead of relying
on active_ids from context, store it once for all at composer level and use
it in code. Active_ids usage is still done at default_get level, using it to
populate the field.
Improve usage of domain, renamed to res_domain to match other document related
fields naming. Add support of a res_domain_user_id field allowing to set the
user from which the domain should be evaluated.
Composer now runs on a list of IDs. Mass mail mode and comment mode are now
distinct from running on a singleton or on more records. Rendered or raw
mode is not triggered by
* mass mailing mode: always display raw mode, whatever the number of records;
* comment mode: display rendered mode when having a single record (like the
previous comment mode). Display raw mode when having either no records
either at least two records.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
When there is not enough recipients for the A/B testing percentage,
we pick a minimum of one recipients (if there is at least one) to
avoid sending a/b test to no one.
task-2713198
closesodoo/odoo#107488
X-original-commit: e1fa7b10250efc790452f02490ab84d2183698ff
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit
- When we were comparing versions, there was no such filter as
mailing type. Due to this it will display both SMS and mail
type records in it.
With this commit
- We have added '('mailing_type', '=', self.mailing_type)' in domain
of compare version.
TaskId-2713198
X-original-commit: e8542e24597ad25b68104c03d4d4ed41e1efac82
Part-of: odoo/odoo#107488
Rename main routes, and keep a legacy for the main unsubscribe route to
keep retro compatibility for existing mailings.
Task-2710804 (Mail: Clean MailThread API)
Task-2669037 (Mass Mailing: Subscription page code cleaning)
Prepares Task-2150462 (Mass Mailing: Unsubscribe flow refactoring)
Part-of: odoo/odoo#106568
PURPOSE
Overall cleaning of subscription and exclusion management code from portal.
SPECIFICATIONS
In this commit we rename methods generating tokens (for recipients and report
management). Otherwise it is hard to distinguish them as naming is not really
convenient to use
* _unsubscribe_token -> was actually generating token for a given recipient
on a given mailing;
* _get_unsubscribe_token -> was actually generating token for mailing
users to deactivate D+1 KPI reporting;
Hash for mail tracking is also moved in its own method to avoid having the
same code twice. Better delegate it to a tool sub method.
Task-2710804 (Mail: Clean MailThread API)
Task-2669037 (Mass Mailing: Subscription page code cleaning)
Prepares Task-2150462 (Mass Mailing: Unsubscribe flow refactoring)
Part-of: odoo/odoo#106568
Currently there are several checks on mailed model directly in code due to
mailing list specific behavior. In order to be easier to manipulate and
a bit less low leve, a computed field is introduced for that purpose.
Indeed there are some behavior changes when the mailing runs on mailing lists
instead of directly on records. There are notably some changes in display
(choose mailing lists but mail contact is the real contact model), and in
subscription page (directly unsubscribe from mailing lists).
Task-2710804 (Mail: Clean MailThread API)
Prepares Task-2150462 (Mass Mailing: Unsubscribe flow refactoring)
Part-of: odoo/odoo#106568
Due to recent improvements (Jinja -> Qweb, safe rendering) rendering API
supports several ways of giving options to the rendering process. Those
have mainly two usage
* ``preserve_comments`` : keep comments in rendered HTML, used notably
in mass mailing or digest to keep browser-specific comments;
* ``post_process`` : perform a post processing on rendered HTML, used notably
to process local links and add tracking to shortened links;
All those are now given directly inside an optional ``options`` parameter
given to ``_render_field`` and its sub-method ``_render_template``.
They can also be defined as field level, using ``render_options`` field
parameter. Some fields are updated
* composer mixin body (which impacts all inheriting models, notably
mail composer, survey and elearning invite wizards as well as appraisal
and appraisal feedback): post processing is now always done by default.
It was already done manually in calls that can be simplified;
* mail template body_html: post processing is now always done by default. It
was already done manually in calls that can be simplified;
* mailing body_html and preview are now post processed by default. It was
already the case in testing wizard. Preview is updated to avoid post
processing of links, as it was before. Remaining use case is the sending
which uses the mail composer, therefore was already post processed;
Finally some 'compute_lang' are explicitly added in _render_field calls in
order to be explicit on what we want, instead of being unsure.
Task-2710804 (Mail: Clean MailThread API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#106072
Purpose is to try to have code easier to read and to update by having a
common way of sorting / writing code. Reorder some fields definitions and
dictionaries, update docstrings, ... in mail applications or when invoking
mail thread API.
Additional stuff worth noting here
* add some tagged in tests helping debugging / choosing tests to execute;
* in a test about mail generation with server action: correctly check
body_html field, not body which comes from the mail.message inheritance
(currently filled due to a side effect but actual field to check is the
html one);
* add same check on input for ``_render_template_qweb`` as done on other
rendering methods (even if rendering on [False] should be supported);
* move code translation update from specific tests into main test class
(code update due to new translations, followup of odoo/odoo@f8c2b02abe);
Some test linting done here
* reorder mail_render tests, remove some duplicated tests;
* reorder mail_template tests, remove some duplicated tests;
Task-2710804 (Mail: Clean MailThread Posting API)
closesodoo/odoo#106025
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
With this commit, the size of the following wizards will be reduced to medium:
\1 Schedule mailing (Email Marketing)
\2 Test mailing (Email Marketing)
\3 Lost reason (CRM)
taskID- 2701035
closesodoo/odoo#96500
Related: odoo/enterprise#29746
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Prevent archiving in-use mail servers by displaying an error message that
lists where it is still used, allowing to easily identify what need to be
updated before being able to archive the mail server.
Additionally,
- prevent the use of archived server as a fall-safe
- when duplicating a mailing with an archived mail server, replace mail
server by the default one
Detailed explanation:
1. A check has been added that raise an exception when trying to connect to the
smtp server or send an email when the server is archived.
With that solution,
- testing the connection of an archived server displays an error telling that
an archived server cannot be used.
- if a mail is still sent with an archived server, mail are in error :
"Connection failed (outgoing mail server problem)"
This fail-safe ensures that no mail will be sent through an archived mail server
and that the user will get some feedback about it.
The same fail-safe for the incoming mail server has been added.
Notes:
- the connection will outlive the archiving of a mail server still allowing
to send email through the archived server until the connection is closed. But
connection are not kept for long so this shouldn't be a problem.
- it cannot be tested because the connect method return immediately in test
mode.
2. When a mail server is archived, an user error is raised if it is in-use.
The implementation relies on each module to override the method
"_active_usages_compute" in "ir_mail_server" to complete the list with
user-friendly message describing the active elements that could send mail
through the mail server. This has been implemented for:
- l10n_it_edi: server used to send e-invoice
- mail: optional server configured for template
- mass_mailing:
-- default mail server
-- active server configured for mailing
Mail server are referenced in other elements but are not active anymore, it is
just for temporary or history purpose. Those references doesn’t prevent the
archiving of the mail server:
- mail_message
- wizard survey_invite and compose_message
- res_config_settings
Task-2821516
closesodoo/odoo#91240
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Right now, on an existing mailing, if we enable the a/b testing and there's
already a campaign set, we remove it and add a newly create campaign that
matches the name of current mailing. Also, while duplicating a campaign, the
`ab_testing_completed` field should not be copied over.
This commit improves the behavior and only creates a new campaign if there's
not one already set on a record, and by preventing `ab_testing_completed`
from being copied.
TaskID-2653806
Part-of: odoo/odoo#77768
When duplicating a mailing with a template already set, especially with a slow
connection, hitting the save button as soon as possible was causing the help
overlay to be superposed with the template. This solves the problem.
Task-2937045
closesodoo/odoo#97930
X-original-commit: 89ecb17f56b34b7e3875fa36cde70a2666dca4d8
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
When we use the "Retry" button in case of a failed SMS mailing, it puts
the mailing back to the queue, which will be processed when on the next
cron call of `Mail Marketing: Process queue` (generally on the next
day). However, it should immediately generate a cron trigger in this
case so that SMS(s) can be sent right away.
The same goes for Email Marketing, where it should immediately generate
a cron trigger so the mailing can be sent immediately.
With this commit, instead of simply putting the mailing back to the
queue, we utilize the method `action_put_in_queue` which immediately
generates the cron trigger in both cases.
taskID-2760101
closesodoo/odoo#94269
X-original-commit: 572a7effb271ad134bb936751292668ae7b2b590
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Seen list (aka already mailed records) computation is done in SQL to speedup
computation. It is based on an heuristic to find fields to check (either
a partner, either an email). However it checks fields are present in model
but does not check they are stored. This leads to traceback if fields
are not stored.
Task-2852943
X-original-commit: fa11070d4533475778ea933225e30d06a09406bc
Part-of: odoo/odoo#94532
Before this commit:
When creating a mail template for a marketing campaign targeting mailing
contact, the reply_to_mode would be set to 'thread', and the reply_to
field would be be read-only. Since there is no way to target a mailing
list from a marketing campaign (see the domain on marketing.campaign's
model_id), and there is no default followers mailing.contact, email
responses would be "lost".
After this commit:
The reply_to_mode is set to 'email', and the reply_to is set
accordingly
OPW-2803314
closesodoo/odoo#94507
X-original-commit: f47da5d3183479597b572046566f67621f6db837
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Francis Sylvain (syf) <syf@odoo.com>
PURPOSE
Reorganize addon according to guidelines, helping finding and updating code.
SPECIFICATIONS
Perform various code linting and cleanups, line breaks, linter issues...
No code or feature change should occur with this commit.
Task-2864264 (Mass Mailing Module Reorganization)
Part-of: odoo/odoo#92509
If you do not have favorite filters available in the mass mailing for
selected model, we display empty drop down, which is not ideal.
This commit improves the behavior with following changes:
- If there is no filter available (for this target) and no condition
set in the mailing domain, do not display anything
- If mailing domain is set but there is not filter available, show a
custom label "Save Filter as Favorite" save icon next to it
Ent PR: https://github.com/odoo/enterprise/pull/26308
task-2711258
closesodoo/odoo#87673
Related: odoo/enterprise#26308
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Steps to reproduce:
- In Marketing Automation - Campaigns
- Select the demo campaign
- Click on "Launch a test"
- Select Brandon
- Send the two mails from the campaign
- Redo all the steps with a new Test but the same contact
Issue:
- The mails won't be sent
Cause:
- Since for this campaign we already sent these mails to Brandon, the mails will be considered as duplicate in:
https://github.com/odoo/odoo/blob/11b7d89114178fa43545fb8e6224cb4ccbcf8ec1/addons/mail/wizard/mail_compose_message.py#L499
Solution:
We want to make sure that:
- when doing a test, since there is only one linked partner to it, we can send as many mails as we launch tests.
-> repeated tests make sense as we want to fine tune campaigns and maybe get feedback from actual customers
- when launching the actual campaign, there are no duplicates (normal flow) but that eventual test-customers receive the final campaign
In order to do that, we have to filter out from the seen_list
https://github.com/odoo/odoo/blob/9b25a4b5a782146e8c0b41eb75ceea7ac3cd3abf/addons/mass_mailing/models/mailing.py#L736
the test-records.
opw-2810298
closesodoo/odoo#92062
X-original-commit: 4cebf53aa89c21ef255f5d5da450fdf98c4c9ac1
Related: odoo/enterprise#27660
Signed-off-by: yosa-odoo <yosa@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
With this commit, when trying to schedule a mailing with a
past schedule_date one will be asked a new date.
LINKS
Task-2833321
closesodoo/odoo#90891
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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
=======
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>
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>
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>
Gorash