`result` might be a Markup object (eg during tests) or a bytes-like object.
Step to reproduce: click on "Send by Mail" on a SO -> Traceback
Step to reproduce (2):
- Install website_sale
- Add something to the cart
- Go through checkout and click on Pay Now
- Crash, 500 error page, as this step is trying to generate the SO PDF to send
by mail to the customer, which tries to encode a bytes-like object.
```
AttributeError: 'bytes' object has no attribute 'encode'
```
But if you do that flow during a test, eg
```
./odoo-bin -d mydb --test-tags=.test_02_admin_checkout
```
You have a Markup object, thus you had to encode it.
Now, even during test, we return a bytes-like object.
Related to #68299
Community: https://github.com/odoo/odoo/pull/75377
Enterprise: https://github.com/odoo/enterprise/pull/20449
Part-of: odoo/odoo#75377
The commit is to refactor the discuss sidebar
- threads are now organized in categories based on the thread type e.g. chat, channel
- categories can be folded or unfolded by clicking the category title
- for active thread, even if the category is folded, it remains under the category title
- for channel category, a new cog button is added to view all channels
- the active indicator bar is removed. The active item now is highlighted with a different background color
- thread avatar is used for livechat, chat and channel
- for livechat and chat, threads are now sorted by last activity time (pin or message exchange)
closesodoo/odoo#70986
Task-id: 2440073
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Reorganize code to ease future additions understanding and setting code
at the right place.
Rename some compute methods to have understandable names.
Remove dead imports.
Fix pytz.utc usage.
No functional change comes with this commit. This is only code move.
Task-2631873
PR odoo/odoo#75571
As mail grows and will continue to grow, ordering views and having right
files is important to understand module organization and content.
Split main.py controller file into two files, one for mail related controllers
(redirections) and one for discuss.
Rename files according to guidelines for wizards and views.
No functional change comes with this commit. This is only code move.
Task-2631873
PR odoo/odoo#75571
As mail grows and will continue to grow, ordering imports and having right
files naming as well as right content in them is important to understand
module organization and content.
Containing
* reorder init file to give an overview of models;
* move ResGroups override in its own file, outside of res_users file;
* split file containing MailActivity model and MailActivityMixin so that
mixin is contained in its own file, easing followup;
* split Activity and ActivityType models into two files;
No functional change comes with this commit. This is only code move.
Task-2631873
PR odoo/odoo#75571
Before:
Only the channel name was updatable and needed refactoring.
After:
The description can be updated as well and both edition have the same
code flow.
task id 2620687
closesodoo/odoo#74962
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The "Message a user" command has been removed because a search with
the @ namespace in the command palette does the same thing.
closesodoo/odoo#75526
Task-id: 2622240
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Following the removal of read access on ir.model (odoo/odoo#69120),
the mail.activity.type model was not accessible to non-admin users due
to the res_model_id many2one field.
Before this commit, a project user could not access the Activity Type
menu.
Convert it to a selection field with the selection values being
computed in sudo.
closesodoo/odoo#74981
Related: odoo/enterprise#20214
Related: odoo/upgrade#2734
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Purpose of this commit is to keep blacklist and optout lists computation
at mailing level and correctly call it in composer. This allow to have
a clearer and more readable code as well as more robust.
Currently it is done by adding this information in context before invoking
the mail composer. It is now correctly done in composer: if a mailing is
linked to the composer, it calls both blacklist and optout lists methods.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
RATIONALE
Prepare code cleaning and optimization in mail, mass_mailing and SMS by
cleaning models for readability and code complexity and footprint reduction.
SPECIFICATIONS
Purpose is to prepare future changes by easing its grep. Notification is too
much heavily used through the codebase and finding it was quite hard among
other noise.
Rename ``notification`` field to ``is_notification``.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Upgrade PR odoo/upgrade#1907
RATIONALE
Currently most of mail related failure types are computed in mass mailing.
This is mainly due to historical reasons. We could move some of this
computation directly at mail level and store failure information directly
in mail.mail records.
SPECIFICATIONS
Overall purpose is to get near SMS implementation where base composer prepare
more advanced pre computation: blacklist, optout, seen list.
Detect and store failure types directly on mail.mail: blacklist, optout,
duplicates, missing email, wrong email, ...
State computation is moved from mass mailing to mail. It is also improved as
currently everything is based on "first recipient found". This is globally
valid for mass mailing who uses default recipients (customer). However when
dealing with generic mailing this is not true anymore.
We choose to store and update status on mail.mail records only when having
a single recipient. When several recipients are defined on a given mail.mail
we cannot really decide a status prior to sending it and skip this computation.
Mass mailing override now uses information from mail.mail to update its linked
traces as computation is now delegated to base composer model.
LINKS
Task ID-2377974
Community PR odoo#61467
Enterprise PR odoo/enterprise#14633
Upgrade PR odoo/upgrade#1907
PURPOSE
Clean mailing code and ease understanding by replacing some old selection
keys by new ones better highlighting their use and aligned with other keys
used notably in mass mailing or SMS.
SPECIFICATIONS
Use shorted and mail-related keys. Indeed we already have sms_ and sn_ for
sms and snailmail related failure type. We therefore update failure_type for
mail as
* "UNKNOWN" -> "unknown", a generic unknown of uncategorized error;
* "RECIPIENT" -> "mail_email_missing", indicates email address is
invalid;
* "SMTP" -> "mail_smtp", connection issue;
"BOUNCE" key is never used and removed. Actually we use a bounce state for
bounced emails / traces so this key has no use.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Upgrade PR odoo/upgrade#1907
PURPOSE
Be aligned with mail_mail model naming as well as convention used in SMS
application (sms_sms_id, sms_sms_int) and mass mailing application (using
mail_mail_id on mailing.trace model).
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Upgrade PR odoo/upgrade#1907
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
RATIONALE
Currently there are differences between mail and sms error management
especially when sending them in batch (mass mode). Moreover cancel
(ignored) and error (exception) states meaning is not clear. Finally
some failure types management between mail and sms can be cleaned.
SPECIFICATIONS
Meaning of ignored / error we want to enforce now is
* error: there was something wrong at sending and user has an action to
perform, i.e. server failed -> check its logs;
* canceled: invalid recipients due to contact information or mailing
configuration (blacklist, opt out, void or invalid email or phone number).
In indicates issues linked to records themselves;
In this task we also add failure information granularity on mailing traces
linked to email like what is done currently on SMS. This can be related to
mailing (blacklist, optout, duplicates) or related to recipient (no recipient,
incorrectly formatted).
We also correctly distinguish optout from blacklist when sending SMS.
SPECIFIC USE CASES
* recipient without email / number: mail / sms is set as canceled, trace is
ignored;
* recipient with invalid email (no @) / number (formatting impossible):
mail / sms is set as canceled, trace is ignored;
-> we now distinguish when possible a void email from a wrong email using
a newly-added selection key (mail_email_missing);
* recipient with email / number blacklisted: mail / sms is canceled, trace
is ignored;
* recipient with email / number that optouted from mailing: mail / sms is
canceled, trace is ignored;
* recipient with email that bounces: mail is sent and will be set as bounce
when receiving bounce in gateway; trace follow same path;
* recipient with number that bounces: not supported as currently no support
of bounce through IAP;
* mail server error, IAP error: mail / sms is set as exception / error,
trace is set in exception;
This means we introduce new failure types on mailing.trace model to reflect
those failure types
* ``mail_missing``: missing email (different from wrong value);
* ``mail_bl``: blacklisted;
* ``mail_optout``: optouted;
* ``mail_dup``: duplicated email skipped during mass email send;
We introduce ``sms_optout`` on SMS and trace models as it was merged with
blacklist previously. Now both errors are distinguished.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Upgrade PR odoo/upgrade#1907
In this commit some reorganization is performed within mail compose message
code. Purpose is to reorder a bit methods by main usage: onchange, CRUD,
actions, values generation with rendering and template management.
Some renaming is performed on action methods, notably send_mail that has some
impact on sub-addons. Finally we also set onchange and sub-onchange methods
private.
No functional change should be implied by this commit.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Purpose is to better understand the use of email_re regex (find emails in a
text) and email_split_tuples (find name and email in a string used in email
headers or as email_from / email_to / email_cc).
Task ID-2377974
Community PR odoo/odoo#61467
Since a few time, test_mail holds tests linked to specific test models.
Generic testing of mail features are located in mail. Followup of fix done
in 12 and forward ported until odoo/odoo@b7af68590e
Also rename test_mass_mailing_server.py unit test file to test_mailing_server
to match current naming of files.
Task ID-2377974
Community PR odoo/odoo#61467
*: hr_holidays, im_livechat, sms, snailmail, website_slides
Most messaging related components have common needs concerning
subscribing to model changes, and not needing to be rerendered unless
their props change. Previously, most components would call the hooks
"useModels" and "useShouldUpdateBasedOnProps" individually. Messaging
components also depend on one another quite a bit, requiring a lot of
explicit imports of other components. It would also be useful to be able
to have cyclic dependencies between component (eg Message renders a
component that allows to delete the message, and the delete component
renders the message in a confirmation dialog), but that doesn't work
with explicit imports (the odoo module system doesn't support cyclic
dependencies).
This commit adds a Component decorator that:
- Registers the component in an internal registry
- Makes all components in this registry available at render time to
components that have been registered in this way
- Calls the useModels and useShouldUpdateBasedOnProps hooks during
component initialization (setup)
enterprise PR: odoo/enterprise#20304closesodoo/odoo#74982
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
PURPOSE
=======
We want to increase the score of the emails sent by Odoo and we want to
avoid them to be marked as spam by the mail clients (gmail, outook...).
SPECIFICATIONS
===============
From filter
-----------
Add a new field on the "ir.mail_server" which is "from_filter". This
field defines the email address for which the outgoing email server can
be used.
The "from_filter" can either define an email address or a domain name.
Use the system parameter "mail.default.from" which allow us to define
a default email address which is used to encapsulate the emails
(default: notifications@<catch.all.domain>).
Mail server priorities
----------------------
When sending an email, we read the FROM header and,
- We first look for a mail server which match the entire mail FROM
in that case, we do not change the email header (not needed)
- If not found, we search a mail server which matches the domain name of
the mail from (do not need to change the headers in that case)
- If not found, find the mail server linked to the "notifications"
email (defined in the system parameter). Then change the FROM header
to the notification email, and put the old one in the name part of
this header.
E.g.
Initial mail from: "Admin" < admin@example.com >
Final mail from: "Admin (admin@odoo.com)" < notifications@odoo.com >
- If no notification email is configured or if no mail server are
found for the notification email, fallback to the old system and
spoof the FROM header. In that case we do not have the choice if we
want to send the email, he will probably be marked as spam.
Sending method priority
-----------------------
In the mail server models, we defined some priorities,
1. Forced SMTP session
2. Forced mail server
3. Try to find the best mail server (see "Mail server priorities")
4. If not found, read the odoo-bin arguments
Bounce
------
As there's no standard for bounce address, we put it in the envelope
(smtp_from). But in some case, it might be considered as spoofing. So,
we use the bounce address ONLY if the mail server is configured for the
entire domain name.
One behavior which might be broken is the following; we send an email as
"std@gmail.com" and the bounce address is on the domain "odoo.com".
Before we received the bounce notifications but we were spoofing the
local part and the domain.
Now
- if a mail server is configured for GMAIL, we do not use the bounce
address (and we might not receive the bounce notification)
- if no mail server is configured for GMAIL, but one is configured for
"odoo.com"
- the FROM header will be "notifications@odoo.com"
- the FROM envelope will be the bounce address
=> In this situation we are spoofing only the local part of the email
but it's allowed as the mail server is configured for the entire
domain name
LINKS
=====
Task-2367946
odoo/odoo#61853odoo/upgrade#1903
The chatter's textarea gets resized dynamically. However no minimum
height is set so we can end up with a height of 0. This was the case
when the chatter was added to a notebook's tab, like in mass_mailing.
This sets that minimum height so it is equal to that of its parent.
Task-2545445
closes odoo#71511
* = test_discuss_full
Overall less queries.
Changes:
- Batch `mail_partner_format`.
- Batch `user.employee_id` compute.
- Remove query for current leave state, use fields (and prefetch) instead.
- Move current leave state in partner format instead of channel info.
Part of task-2622462
closesodoo/odoo#73174
Related: odoo/enterprise#20186
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* = hr_holidays
This new module will contain more tests as time goes on.
This new test will serve as indicator for future performance improvements.
Fix missing `flush` before query in `hr_holidays`.
Part of task-2622462
* = im_livechat, test_mail
The goal of moving it in models and making it independent of current user is to
be able to test it easily in future commits.
Part of task-2622462
* = crm_livechat, im_livechat, mail_bot, test_mail_full
Those are hard-coded methods just like any other, remove the magic call and the
need to forward them to the client at init.
Part of task-2622462
Ticket: 2578903
In the overview menu, the time of a calendar event was not formatted according to the user preferences. This PR fixes that.
closesodoo/odoo#75039
X-original-commit: 0f9746adab26a792fba5d9cfe8e30ea90d7c2a67
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
Signed-off-by: Hubert Van De Walle <hubvd@users.noreply.github.com>
Francois (fge)