Currently, a logger exception is generated when the user tries to upload
any image as document in the mass mail.
This is because an UnidentifiedImageError occurs when the user uploads
an image file as a document and code [1] tries to open it with Image.
This commit adds code that handles an UnidentifiedImageError, and it adds
the message in the log for an invalid image file.
[1] - https://github.com/odoo/odoo/blob/029b84f3c061f819bacb9a4818504cced4adeb1c/addons/mass_mailing/models/mailing.py#L1405
sentry-4311184876
closesodoo/odoo#159653
X-original-commit: e4b7ec191fc81ec806736758f273e20b6260bbeb
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: ANSARI MAHAMADASIF (maan) <maan@odoo.com>
With 17.0 the `mail.alias.domain` was introduced, allowing the
configuration of the bounce, catchall and default from email addresses
at the company level (`res_company`).
For this purpose, the `_compute_email_from` method was introduced to correctly
compute the `email_from` in various email contexts.
But, the `email_from` field in mass_mailing was using an obsolete combination
of `default=` and a compute method.
This meant that when one created a new `mailing.mailing` record, it was
always defaulting to `self.env.user.email_formatted`.
The compute was only triggered when the `mail_server_id` field manually
updated.
This is corrected with this fix and a unit test was added to test three
different use cases.
An invisible `create_uid` was added to the base mailing From view xml
to have the compute method trigger correctly in some unit tests.
How to reproduce bug:
See related github issue https://github.com/odoo/odoo/issues/151310
Behavior after this fix:
If `mail.alias.domain` is setup for the company and a default `ir.mail_server`
is configured for Email Marketing, `_compute_email_from` will select
the expected `email_from` at record creation for `mailing.mailing`.
opw-3704715
Fixes#151310
commit 4b5453d87498d32b0ec3e3e7d64d35f903ac2193
Author: jorv <jorv@odoo.com>
Date: Mon Mar 18 15:30:06 2024 +0100
[FIX] mass_mailing: precompute email_from based on alias domain
With 17.0 the `mail.alias.domain` was introduced, allowing the
configuration of the bounce, catchall and default from email addresses
at the company level (`res_company`).
For this purpose, the `_compute_email_from` method was introduced to correctly
compute the `email_from` in various email contexts.
But, the `email_from` field in mass_mailing was using an obsolete combination
of `default=` and a compute method.
This meant that when one created a new `mailing.mailing` record, it was
always defaulting to `self.env.user.email_formatted`.
The compute was only triggered when the `mail_server_id` field manually
updated.
This is corrected with this fix and a unit test was added to test three
different use cases.
An invisible `create_uid` was added to the base mailing From view xml
to have the compute method trigger correctly in some unit tests.
How to reproduce bug:
See related github issue https://github.com/odoo/odoo/issues/151310
Behavior after this fix:
If `mail.alias.domain` is setup for the company and a default `ir.mail_server`
is configured for Email Marketing, `_compute_email_from` will select
the expected `email_from` at record creation for `mailing.mailing`.
opw-3704715
Fixes#151310closesodoo/odoo#152655
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before: When a user receive a mass_mailing and click on the
unsubscribe button, he arrives on the unsubscribe webpage where
the first sentence stay in english whatever the website language
Step to reproduce:
- Create a db with the email marketing and web module
- Create a mailing list with at least one recipient
- Send the mailing (catch the email with an email catcher, ex: mailhog)
- Click on the unsubscribe button
Now: The first sentence is in the website (or portal) language
opw-3538873
closesodoo/odoo#152579
X-original-commit: 6ba3dc277b9bf6b093eeefe889f20734ae4d135b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, base64-encoded images were converted to attachments
only for the body_html field, leaving the body_arch's content unchanged.
As a result, every time a record was updated, the body_html content,
which is generated from the body_arch's content, would have the same
base64-encoded images, which were converted again to new attachments.
Moreover:
- the created attachments were not linked to the mailing record (no
res_model and res_id).
- the attachment name contained "cropped_image", even for images that
were not a result of cropping.
- when the image conversion happened for a record in creation, the
resulting attachment name was "cropped_image_mailing_False_0" (or any
other number, the relevant part is "False", where the record's id was
expected).
- the body_arch could take an excessively large amount of space in the
database table, due to its base64-encoded images (see [1]).
This commit makes sure the body_arch has its images converted to
attachments as well, and also makes sure such attachments are reused
when replacing the image sources in the body_html, instead of creating
new ones.
Besides, the "cropped_image_mailing" in the attachment's name was
replaced by the more generic "image_mailing".
Lastly, when a record is being created, the conversion to
attachments now happens after the call to super().create, so that the
record's id is known when creating attachments.
task-3479586
[1]: https://github.com/odoo/odoo/pull/128452
X-original-commit: 9c5a56d2be9c1a480d526755327c79e2daa90a35
Part-of: odoo/odoo#152065
do not compare types, for exact checks use `is` / `is not`,
for instance checks use `isinstance()`Flake8(E721)
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
ISSUE
=====
clicks_ratio uses a formula that is not relevant as it accounts
for emails that could not lead to a click. It divides the
number of clicks by the total of expected emails instead of
substracting cancelled ones.
HOW TO REPRODUCE
================
1. Create a mailing M
2. Create a mailing list of 5 contacts with same email adress
3. Create a link tracker associated to M
4. Send -> 4 emails will be canceled as same email is used
5. Click the link.
6. Ratio of 'clicked' on the mailing view will be 20%
instead of 100%
FIX
===
Only use mailing traces where trace status is not 'cancelled';
aligning the formula to other stats set in _compute_statistics.
The formula becomes:
CR = # clicks / (# total_traces - # cancel_traces)
A test on statistics is modified to check this behavior.
Task-3607171
closesodoo/odoo#148551
X-original-commit: 5dc7c6102f1d23ffa02d3b6aff3c518204fb4566
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose:
- Changed the default value of 'Show In Preference' (is_public) field from true
to false for preventing the automatic publishing of mailing lists.
Task-3594678
closesodoo/odoo#144699
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
- using a string to join `Markup`s is useless, that just strips out
the `Markup`
- the entire toplevel `Markup` can be formatted in one shot
closesodoo/odoo#140428
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Also impacts mass_mailing_sms, test_mail_sms,
test_mass_mailing
This PR adds support to receive sms delivery reports.
Before this PR, an SMS was considered 'sent' when successfully
handled by the third party. The user couldn't know if/when an
SMS was actually sent for delivery or delivered to the
recipient's device.
This was similar to the behavior for emails as delivery reports
are not commonly used (and not supported in Odoo).
With this work, the SMS `pending` state is introduced in mail,
mass_mailing, sms and mass_mailing_sms contexts although only fully
used in the latter two modules (+tests of course).
Because of the huge cost related to upgrading very large existing
databases, the following compromises were made:
1. An email and sms notification/trace SENT means DELIVERED.
Those that are sent but NOT DELIVERED are PENDING.
The difference between email and sms traces reinforced with this PR
is that an email sent will be counted as "sent" ~ "delivered"
unless an error is returned for emails while for SMS it can only be
reached if a delivery report is received.
2. The Link between an SMS uuid (shared with trusted parties) and
the tracking records (notifications or traces) is done via an
explicit relationship table (sms_tracker) instead of via a new field.
This however allowed to nicely concentrate the state update logic.
A `process` state is added to represent an intermediate
step in the sending process, such as held at IAP for SMS.
A few adjustments are also included to update for IAP api v3.
Also, adapts and includes new tests.
Task-2560666
Part-of: odoo/odoo#133392
The system tray has been simplified:
- only one clickable area per activity group
- by default, a click on an activity group open the list view, except for some
model (ex.: journal entries, project, task, documents where the activity view
is opened). This can be defined per model using the _systray_view attribute on
the model.
- the clock icon providing access to the activity view has been removed. As it
is the only action, we also remove "actions" returned by systray_get_activities
in res_users.
- the KPIs are no longer clickable
The tests have been updated (for example, because we open the list view instead
of the kanban view) and one removed "activity menu widget: activity view icon"
as we only have one clickable area now and no more icons.
Task-3300854
Part-of: odoo/odoo#138135
This commit introduces a button "Send New Mailing" & "Send New SMS" on the mailing
list so that one can direct send mailing & sms from a mailing list.
The current list will be set as default one in the mailing.
TaskId-2702607
Part-of: odoo/odoo#82107
- Before this commit, it could happen sometime that the time for
which mailing was schedules has passed, but user was still
getting the same ribbon that mail was scheduled for a particular
time (which is a bit confusing). And also in the case of
schedule_type equals to now we are displaying the next_departure
datetime in ribbon.
This commit improves the behavior and in such cases, displays a new
ribbon message saying "This mailing will be sent as soon as possible."
and has as refresh button next to it, which reloads the page. Once
the mailing is sent, this ribbon will also be hidden.
For that, we introduce a new compute boolean `is_past_departure` which
will be true only if the scheduled time is in past and the mailing is
still in queue.
And for the case scedule_type equals to now we are displaying
a new message on ribbon with refresh button.
- Re-arranges the model container part of the form view of
a mailing in order to utilize the horizontal space.
It moves domain next to the model / filter related fields so that
everything is in a single row, and thus reducing vertical space.
TaskId-2702607
Part-of: odoo/odoo#82107
Purpose of this commit is to try to detect and log 'email_from' invalid
values when sending emails based on outgoing 'mail.mail'. This implies
checking the returned messages when having a generic Exception when sending
the emails, as we distinguish two use cases that raise through a simple
raise: missing from and invalid from.
New failure types 'mail_from_missing' and 'mail_from_invalid' are also
added at 'mail.notification' and 'mailing.trace' level, as other failure
types.
Task-3547653 (Mail: Add error type for wrong email_from)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
closesodoo/odoo#138202
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit:
In the `mailings` when we enable the A/B testing and click on the "Create an Alternative" button,
the "Send final on" field doesn't copy to the new mailing.
Reason:
The related field are copy `false` by default.
After this Commit:
Now it will copy the "Send final on" into a new mailing
closesodoo/odoo#138195
Task: 3465887
X-original-commit: 3d6dd2402a65af40c77692250fd710d3355960e7
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Globally improve usability and features given by mailing portal about exclusion
list and opt-out management.
SPECIFICATIONS
Add unsubscribe headers to email sent by mass mailings. As emails are already
parsed to change the generic 'unsubscribe_from_list' link to an email-specific
link we can add the List-Unsubscribe header at the same time. Add header for
post 'List-Unsubscribe=One-Click' to avoid one-click unsubscribe when readers
crawl email links.
Task-2150462 (Mass Mailing: Improve subscription management)
Part-of: odoo/odoo#86084
PURPOSE
Globally improve usability and features given by mailing portal about exclusion
list and opt-out management.
SPECIFICATIONS
Messages and notes are improved to have a better wording and links to contextual
records when possible (mailing, mailed records, contacts, ...).
Add opt out reasons when updating subscriptions or block list status. This
allows to better report on common causes.
For that purpose we introduce a new model allowing to store those reasons.
A boolean flag allow to trigger the usage of the feedback textarea in portal
page.
Task-2150462 (Mass Mailing: Improve subscription management)
Part-of: odoo/odoo#86084
PURPOSE
Overall cleaning of subscription and exclusion management code from portal.
This code comes mainly from v12 and can now benefit from cleaning and update.
SPECIFICATIONS
In this commit we rename ``mailing.contact.subscription`` model into the
shorter ``mailing.subscription``. This is sufficient to explain the model
purpose. As we plan to add an opt-out model this also allows to have sub
models with suffixes without being too long.
We also rename ``subscription_list_ids`` field on contact model to
``subscription_ids`` as this is shorter and clearer.
Finally the ``mailing_contact_list_rel`` table name that comes from old
implementations (simple m2m table) is renamed to ``mailing_subscription``
to match the model name.
Task-2669037 (Mass Mailing: Refactor js/portal for subscription)
Part-of: odoo/odoo#86084
PURPOSE
Overall cleaning of subscription and exclusion management code from portal.
This code comes mainly from v12 and can now benefit from cleaning and update.
SPECIFICATIONS
Rename route parameters to be more clear about their usage. Notably res_id
is better labelled document_id, token is a hash_token, ...
Update legacy to still support old routes.
Task-2669037 (Mass Mailing: Refactor js/portal for subscription)
Part-of: odoo/odoo#86084
PURPOSE
Overall cleaning of subscription and exclusion management code from portal.
This code comes mainly from v12 and can now benefit from cleaning and update.
SPECIFICATIONS
Purpose of this commit is to cleanup code that manages chosen lists from
portal and updates opt-in and opt-out accordingly.
Code is now located on mailing list model. When opting-it, new subscriptions
have to be created for mailing lists so that email is part of the list. When
opting-out we just have to toggle the opt_out flag on subscription model.
Logged messages are also improved. We log on contact model the updated
mailing lists for opt-in or opt-out.
Task-2669037 (Mass Mailing: Refactor js/portal for subscription)
Part-of: odoo/odoo#86084
Use name instead of email, as contact is notably used in sms marketing
application with mainly phone numbers. Better use the name as primary
ordering field. Then use ID to avoid non deterministic behavior.
This requires to fix some tests in 'test_mass_mailing' so that they
use test models instead of existing models. That way they are not
dependent on existing data and existing models definition anymore. An
issue with ordering rose as we modified the ordering of contact model.
Task-2150462 (Mass Mailing: Improve subscription management)
Part-of: odoo/odoo#86084
PURPOSE
Slightly modify various apps to improve the user experience. Changes include
notably labels and views fine tuning, roundings, and small css fixes.
SPECIFICATIONS
- Remove the decorator from the event list view as it's a bit confusing
- Ensure mailing KPIs are now shown with 2 decimal places
- Re-order the mailing stat buttons
- Improve the background / font colors of the cover block
- Improve the labels of:
- Title and confirm button of the /button and /link modals
- Confirm button when archiving a record
Task-3204554
closesodoo/odoo#128108
Related: odoo/enterprise#43937
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before the commit, the _get_seen_list() function in the mass_mailing module was
not able to correctly identify all the duplicate email addresses in a given mass
mailing. This was because the function chose and used only one way to find an
email address for each record in the mailing list, even though there are many
ways to find an email address for a record.
For example, a crm.lead record might have an email address in its partner_id
field, but it might also have an email address in its email_normalized field.
This can vary from record to record.
To fix this issue, the _get_seen_list() function was updated to only look at the
email address to which emails have already been sent, rather than trying to
fetch it from the record itself. This ensures that all duplicate emails are
correctly identified and that no duplicate emails are sent in the mass mailing.
Task-3234378
closesodoo/odoo#135081
X-original-commit: 66f9aa25af049aa3faf0f76475a4a2b63b5d0903
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS: MAIL COMPOSER IN MAILING
When using the composer with a mailing, it currently skips recipients whose
email is a multi-email due to the strict usage of 'email_normalize'.
We can improve multi-email support by effectively checking for the first
email found, using the "less strict" mode of normalize. It means more emails
are detected as valid, and therefore sent.
Due to lower support of multi-emails when sending emails, this even allows
to send multiple emails as all emails are mailed.
SPECIFICATIONS: DEFAULT RECIPIENTS
Mailings are generally done using default recipients, aka using a model method
that returns the people to mail: customers ('partner_id'), customer emails
('email_from'), specific implementation, ...
This is implementation using '_message_get_default_recipients' that returns
'partner_ids', 'email_to' and 'email_cc' that are then used in the mail
composer to generate final recipients.
In this commit we better handle the content of email fields to avoid issues
with multi-emails. For that purpose we correctly split the content of those
fields. We now have several 'email_to' for records having multi-emails instead
of a single badly-formatted 'email_to'.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@4a0d87d44f
Part-of: odoo/odoo#134934
As it already normalizes returned emails some manual calls to 'email_normalize'
are not necessary. Some variable names are updated to be clearer about the
email being normalized.
Parsing contact name and email is also moved into a tool function to avoid
using a partner environment just for a tool parsing method.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@f7add44c28
Part-of: odoo/odoo#134934
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
Mahamadasif Ansari