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
The previous commit introduced an optimization to reduce the number of
queries and fields fetched when we call `name_search`. But it works much
better when the dependencies of `display_name` contain field names used
in the calculation (on the same record/model).
Then, to improve the performance and the cache coherency, add `depends`
and `depends_context` depending on the custom `_compute_display_name`.
Add only the first level of dependencies (never traverse relational
field) because only these have a positive impact on the previous
optimization and the cost is very low (see `modified`).
About `depends_context`, we don't include `lang` because (when `_` is
used by example) it is unlikely to get the same display_name in the same
request with two different lang.
closesodoo/odoo#122085
Related: odoo/documentation#4639
Related: odoo/enterprise#42599
Related: odoo/upgrade#4780
Signed-off-by: Raphael Collet <rco@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
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
In this commit we remove overrides of create / write on subscription model to
make 'unsubscription_date' an editable computed field instead.
While being there, tracking on blacklist model is ordered, as a side dish
to prepare other mailing improvements.
Prepares Task-2150462 (Mass Mailing: Improve subscription management)
closesodoo/odoo#122106
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Oversight of odoo/odoo@e7c2209406 . A whole model was duplicated due to a
bad conflict resolution. Indeed 'mailing.contact.subscription' model has been
moved into its own file at odoo/odoo@4f39a80e76 but original code was
added back in the contact file when forwarding the bug fix.
As model was created / defined twice, the second definition was simply
overriding the first one, hence no issue arose.
Prepares Task-2150462 (Mass Mailing: Improve subscription management)
Part-of: odoo/odoo#122106
Ensure computed fields are triggered on time and using the right values.
Add missing triggers and flush to ensure computed fields are computed when
necessary. Also fix some typos in comments of sub-methods used in those
computed fields.
Prepares Task-2150462 (Mass Mailing: Improve subscription management)
Part-of: odoo/odoo#122106
*: mass_mailing_themes, website_mass_mailing
This commit adds TikTok to the already existing social networks in all
email marketing templates (droppable blocks and default mail templates).
task-3235451
closesodoo/odoo#116837
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Allow partner to unfollow a document from a follow up email of that document
through an unsubscribe URL in the email even if not connected.
It works for internal user for follow up on any document and for any partner on
follow up of document tagged as authorizing being unfollowed by any partner (
slide.channel and slide.slide).
Technical note:
The unfollow block is rendered in mail_thread and updated for each recipient in
mail_mail. We don't render it in mail_mail because we don't have the language
of the message at that point.
Depending on the partner and the related document, the unfollow block is:
- either removed if the user cannot unfollow the document (for example if it
doesn't follow it)
- or updated with partner and document information + a security token
Task-3061864
Part-of: odoo/odoo#107978
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>
Bug
===
Since 6185f14807 we check the <mail.mail>
existence before marking the <mailing.trace> as opened, but since
57ae1b9b8b61f5f4719a8a81e9d0d21fab58cfda we remove the <mail.mail>
automatically when we send them.
The result is that this endpoint always raise a 500 error.
To be: the <mail.mail> existence shouldn't be checked in this endpoint
(the token is valid for the raw integer id).
Task-3234519
closesodoo/odoo#115842
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>
Purpose
=======
The bounce emails aren't stored in Odoo, which can complicate the
debugging of the email sending.
Now, we store this bounce email, and we allow the user to read it from
the interface, so he can easily find the issue when an email sending
fail.
Specifications
==============
The bounce email is stored on the mail notification for standard emails
sending, and on the mailing traces when using mass mailing.
For some email providers (e.g. Yahoo), the "Final-Recipient" header is
not present. Normally, it allows us to retrieve the original recipient
of the email which bounced and then the partner. So if this header is
not there in a bounce email, we take the first recipient of the parent
<mail.message>.
Change the way that we parse the email body, for the bounce email.
For most email providers, the first mail body is the one that contains
the error and the next one contains the parent email body. So, the
current logic might ignore this body for Outlook and Yahoo.
Task-2116296
closesodoo/odoo#105923
Related: odoo/enterprise#34051
Signed-off-by: Warnon Aurélien (awa) <awa@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
Purpose is to rewrite value generation as code is messy with a lot of dict
updates, rewriting key on top of existing keys until reaching the final value.
In this commit we better split computation, to have computation that is static
(currently, posting a comment as composer holds final code) separated from
dynamic computation (posting a mass mailing, as rendering is done based on
qweb or inline template value).
It allows to better understand how composer and template fields are used when
sending emails or posting messages. This commit should not change anything
functionally, even if some values are weirdly computed. Future commits will
improve support of composer / template fields, notably through computed field
and less cross computation.
Also split sending methods: do a mailing in batch in case of mass mailing
(allowing commit per batch), and simply loop on records to post a message
in case of comment (or mass post).
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#99482
RATIONALE
Purpose of this commit is to cleanup main post helpers and have a more easy
and understandable way of calling them.
SUMMARY
We now have two main API methods, based on business flow: either posting
on documents, either sending a mass mailing. Indeed those two flows are
different
* post: create message, then launch notification process by taking into
account subtype, followers, ...
* mail: create mails in batch with recipients being based on template or
given partners. No notifications is involved, only maybe traces if a
mass mailing is linked
Delegate QWeb rendering to the render mixin (i.e. _render_template_qweb_view)
in order to have a single point to forge evaluation context and re-use
existing rendering code.
SPECIFICATIONS
Main API helpers are now
* ``message_post_with_source``: (batch) post on records, using an ir.ui.view
(given a record or its xml id) or a mail.template record (given a record or
its xml id). When using a template, a composer is called to post on each
record (as batch post is not yet supported). When using a view, a direct
call to message_post using the rendered bodies is done, one record at a
time.
* ``message_mail_with_source``: send a mass mailing on records, acting like
invoking the mail composer in mass mode. Same arguments are valid, either
a reference to a view, either a reference to a mail template.
Other helpers are
* ``_message_log_with_view``: (batch) log on records, using an ir.ui.view
to render the body using QWeb (no notification process);
* ``_message_log(_batch)``: (batch) log on records (no notification process);
* ``message_notify``: notify partners on records (creating notifications
specifically for some people while message itself is not displayed in
chatter);
Code migration
* ``message_post_with_template`` in "mass mode": use ``message_mail_with_source``
and set the template record as source;
* ``message_post_with_template`` in "comment" mode: use ``message_post_with_source``
and set the template record as source;
* ``message_post_with_view``: its main usage was to post on a document, in which
case it generally can be replaced by ``message_mail_with_source`` using
the view reference as source;
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
RATIONALE
Purpose of this commit is to be explicit in subtype chosen when invoking the
message composer / calling message_post. As default value may not always be
clear, better be explicit in case the composer default value changes.
SPECIFICATIONS
Add explicit references to subtype when it is not obvious what will be the
final subtype, notably when using helpers (post_with_view or template which
uses the composer that is not crystal clear in its subtype management).
In this commit we also add support of XMLID-based subtype when invoking the
composer. A ``default_subtype_xmlid`` context key is transformed into a
``default_subtype_id``, to be used notably in JS where we cannot easily
use a ``ref``-like statement. Post API now also supports 'subytpe_xmlid'
argument allowing to give the xml id and ease calling the methods.
Use ``_xmlid_to_res_id`` to get directly the ID of subtypes in order to
avoid useless queries from ``ref`` that does an exists.
Also remove useless values given to post API, notably author_id that is by
default the current users' partner.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
RATIONALE
When sending a ``MailMail`` some data preparation is done. This is done
directly in ``_send`` and in sub-methods. As a given MailMail may lead to
several emails being sent we have to go from a mail to a list of emails
to send :
* one email for ``email_to``. They all receive the same email, as those are
just a list of emails to contact and no specific post-processing is done;
* one email for each partner in ``recipient_ids``. It enables a partner-based
update of the body, for example for links or traces in mass mailing;
SPECIFICATIONS
In this commit we move code so that all preparation is done in a sub-method
``_prepare_outgoing_list``. That way it can be cleanly overridden to add or
modify values before sending the actual emails.
This commit does not change behavior and calls done to ``build_email``. This
will be updated in the next commits, notably to improve "cc" management.
Task-2710804 (Mail: Clean MailThread Posting API)
Task-3093268 (Mail: Stop spamming CCs)
Prepares Task-2684479 (Mail: Better report errors when sending emails)
Part-of: odoo/odoo#99482
The goal of this commit is to fix the problem introduced by the PR 106519.
How to reproduce the problem:
- Go to the "Email Marketing" app
- Go to the "Mailing Lists" menu
- Click on a "Mailing List"
- Click on the "Recipients" stat button
- Click on the "Import" button
Before this commit:
A dialog opens and no mailing list is selected.
After this commit:
A dialog opens and the mailing list we are in is selected.
closesodoo/odoo#106732
Related: odoo/enterprise#34453
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In this commit, we will convert all the customisations of the list view
consist in adding an always present button in the control panel that
performs an action/calls a model's method.
To do this, we will use the new display="always" parameter applicable
to buttons in the header of list views. This allows us to define a
button that is always visible in a list view.
closesodoo/odoo#106519
Taskid: 3082303
Related: odoo/enterprise#34387
Related: odoo/documentation#3044
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
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
Before this commit when creating a mailing contact with a mailing
list opt_out at creation the unsubscription_date wasn't set.
Indeed, from the mailing contact view the mailing list uses an
editable list that passes all the values at create even when not set
contrary to when one update the contact only the changed values are
passed. This commit fix this issue.
Task-3070852
closesodoo/odoo#106682
X-original-commit: e7c22094068ce5cdff7f30178cea6d4f39f09137
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Hoste Patrick (pko) <pko@odoo.com>
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
Purpose of this commit is to use the newly introduced feature to log a message
when adding or removing an entry in block list of emails in email marketing
application.
Logging itself is improved, as it now contains
* source of the request (unsubscribe link, or manual ask through the portal
unsubscription page);
* link to the source mailing;
* link to the document that generated the click (a mailing contact, a sales
order, ...);
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
This commit adds a new group `ab_test_group` after notebook of campaign form
view, which displays A/B test related information. Below are the fields
displayed within the group:
- ab_testing_winner_selection
- ab_testing_schedule_datetime
They will become readonly as soon as the the A/B testing is completed.
Apart from that, this commit makes the mailing/sms mailing lines editable.
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>
Gorash