Before this commit, processing of pinned channels during
init_messaging was slow due to sorting them in sidebar
of discuss.
This commit improves the sort so that we do a binary insertion
on add rather than push + quick-sort.
Before what took 2.2 seconds now takes around 0.6 seconds.
closesodoo/odoo#108839
X-original-commit: dd4c3c0a8e38147065980cf2c431b056a5253255
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Since #107916, the ActivityModel did not include
`["activity_ids", "!=", false]` in its domain, causing incoherence in
some views and resulting in crashes.
To reproduce the issue:
- In the runbot, navigate to Website -> eCommerce -> Product.
- Switch to the activity view.
- Remove the Published filter.
- The view crashes due to an incoherence between the data records
in the `web_search_read` and the `get_activity_data` calls.
This commit resolves the issue by correctly setting the domain.
closesodoo/odoo#108807
Signed-off-by: Luca Vitali <luvi@odoo.com>
*: project, web
This commit converts the Activity view to the current framework shared by
other views. Instead of extending Kanban view/elements, the Activity view
has been implemented by its own.
The project customization of the view has also been converted, as legacy
files have been removed.
Some tests have been adapted since some classnames might differ from the old
implementation, resulting to failing tests. But the overall testing cases
have been conserved.
closesodoo/odoo#107916
Related: odoo/enterprise#35177
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Florent Dardenne <dafl@odoo.com>
The field `notified_partner_ids` has type Many2many with relation table
`mail_message_res_partner_needaction_rel` [1] which is a regular Odoo model
`mail.notification` with some extra fields. One of those fields is required:
`notification_type`.
On copying `mail.message` record, ORM copies Many2many fields directly without
using `default_get` method for `mail.notification` model. Particularly,
`notification_type` get null value and we get an error.
STEPS
1. Create Server Action for `mail.message` model:
```py
for message in (records or record):
message.copy({
"subject": message.subject + "(SA copied)",
})
```
2. Add contextual action
3. Open `mail.message` which has non-empty value on
`notified_partner_ids` (*Partners with Need Action*)
4. Run the Server action via Action menu.
PROBLEM
```
ValueError: <class 'psycopg2.errors.NotNullViolation'>: "null value in column
"notification_type" of relation "mail_notification" violates not-null constraint
DETAIL: Failing row contains (11, 210, null, 3, null, null, null, null, null,
null, null, null, null).
```
SOLUTION
Fix it by adding `copy=False`, because we don't want to copy those values
anyway (confirmed by TDE).
[1]: The relation table is renamed to `mail_notificaiton` in v15+
opw-3069556
closesodoo/odoo#108599
X-original-commit: d68b0f7d6b8f973ddaafdd7526d4f753a1b6abd2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Purpose of this commit is to add tests to check current behavior of composer
when he is updated with Falsy values :
* template set, with void value for some fields that may reset or not
existing composer values;
* template being set to False, check what happens with composer values
(kept or reset);
This may change in a near future but at least it will be documented.
Task-2710804 (Mail: Clean MailThread Posting API)
closesodoo/odoo#108320
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Some tests are basically trying some combinations of composer parameters.
Currently only composition mode is a parameter but we will soon add the
batch mode, as it will be dissociated from the mailing mode.
To ease debugging, let us use subTests when possible, even if this creates
some diff due to the new indentation level to add.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#108320
Purpose is to cleanup and add some details in some tests, notably about
default values when using message_post wrappers with either a view or
a template.
Tests with void recordsets are also added to check their current behavior
and try to keep it consistent when cleaning code in a near future.
Add a missing mute logger.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#108320
Some mail clients set a wrong content-type for PDF attachments, they
set `binary/octet-stream` which doesn't exist[^1]. Odoo would crash
with a traceback in case it tried to extract the content of such
malformed attachment because Python doesn't know how to decode such
content-types.
Looking at the actual content of the emails we received, we would had
expected the content-type to be `application/octet-stream` instead. It
is fair to assume that the mail client software is buggy or poorly
configured and that it assumes that `application/octet-stream` and
`binary/octet-stream` represent the same thing.
Following Postel's Law[^2], it is better to still handle those malformed
emails, assuming the content-type is `application/octet-stream`.
opw-3030113
opw-2716507
[^1]: https://www.rfc-editor.org/rfc/rfc2046#section-3
[^2]: https://en.wikipedia.org/wiki/Robustness_principleclosesodoo/odoo#107317
X-original-commit: e6169325b968711a0a28444818b34aa1932a6bae
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Julien Castiaux <juc@odoo.com>
Warn user and alias responsible when model creation fails on incoming
message due to alias mis-configuration.
Alias custom default values that references archived or deleted records can
prevent the record to be created when receiving an email.
Unfortunately, correcting values on the fly has too many downsides:
- as the value cannot come from nowhere, we would probably end up with
corrupted record like a task without a project
- as errors are silent, lots of suboptimal record could be created before it
is corrected
- as the code would have to deal with different kind of updates, it would be
heavily depend on the framework meaning additional maintenance cost
- the attempt made had also a performance cost by using savepoint which we
want to avoid
For all those reasons, we have decided to warm the user rather than trying to
solve the problem automatically.
The users are warned:
- through a bounce email sent to the sender and alias responsible
- in the alias interface through an alias status present in the list and the
form view
Technical notes:
- They are multiple kind of errors: error in the message (ex.: user not
authorized to send to a specific alias), error in the alias (ex.: dangling
reference in alias_defaults), other error (ex: technical error like a
service unavailable when receiving the message). Here, we want only to detect
alias error and skip other errors. So rather than doing a big try except around
_message_route_process, we have selected the spot where we should detect alias
error:
-- in _alias_get_error_message where we distinct a message error from an alias
error
-- in inside _message_route_process where record are created using
alias_defaults (custom values with reference to record that might have been
deleted since the alias creation)
- In test, we call mail.thread message_process with sudo as it is the case in
real use case (processed when fetching mail). It is needed as in some test
alias status are modified.
Task-2675209
closesodoo/odoo#101019
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The goal of this revision is to add a group
`mail.group_mail_notification_type_inbox` which is granted
automatically when the user `notification_type` is set to `Inbox`
to be able to easily hide the filter `Unread messages` when
the user uses the `Email` notification type,
by simply adding `groups="mail.group_mail_notification_type_inbox"`
on the filter rather than overriding `_get_view` in every model.
The code overriding `_get_view` of `project.task`
to hide the filter "Unread messages" replaced
in this revision initially comes from
odoo/odoo@da868d28e2
> - In project.task search View:
> - the filter for unread messages should be visible only if the current user
> managing his notifications in Odoo
The above revision was part of the task 2844212
closesodoo/odoo#104328
Related: odoo/enterprise#33338
Related: odoo/upgrade#3996
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Update to current runbot state, in order to better spot changes potentially
introduced with this PR.
Task-2710804 (Mail: Clean MailThread Posting API)
closesodoo/odoo#106182
Related: odoo/enterprise#34197
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to add tests on translations when using templates
and composer, on both email content (body, subject) and email layouting
content (view content, groups-based buttons, ...). This better highlights
some missing part of translation support, notably
* when being in mass mode: as content is taken from the composer and rendered
dynamically, it does not take the original translation from the template
even if it matches template content exactly;
* access button title is not translated as it is added during a separate
part of the process;
We also improve tests for ``mail.composer.mixin``. The wizard used in test
(mail.test.composer.mixin) is improve to behave more like a real invite
wizard: it runs on records (mail.test.composer.source) which are records
on which dynamic content is rendered. This highlights one issue with
translations: translations are fetched on current model (aka: composer
body and subject fields). However when using templates, translations are
stored on template model (aka: mail.template). This will be improved soon
by trying to fetch template translations when composer content matches
content from template.
Task-3046371 (Mail: Improve language propagation in mail and layouting)
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>
Notify the user when added as follower by the mean chosen in his/her
preference (inbox/email) and not exclusively by email as before.
Task-2960281
Part-of: odoo/odoo#99371
If source is something like
"admin@éxample.com" <admin@éxample.com>
candidates founds are
['"admin@\xc3\xa9xample.com"', 'admin@\xc3\xa9xample.com']
and the first one raises an error because of "".
Malformed addresses should be ignored.
opw-2982426
closesodoo/odoo#102353
X-original-commit: 35ad2dd630a8ed173c6a9275585eac46b9a19363
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Julien Castiaux <juc@odoo.com>
Currently when creating a composer in mass mode
the composer always shows the 'mass mailing name' option
even when a mailing cannot be created.
This silently creates a regular mass mail.
This hides that option when selecting records of models
that do not inherit from thread. So that users do not falsly
believe a mailing will be created.
task #2990447closesodoo/odoo#102105
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit replaces two usecases of the legacy FormViewDialog and
SelectCreateDialog, as we are about to remove them.
closesodoo/odoo#101819
X-original-commit: b1574ae38be45e871e505100c2342887ed7dba8b
Related: odoo/enterprise#32132
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Website: the context install_filename='dummy' is used to prevent
arch_updated from becoming True while updating translations of
ir_ui_view.arch_db (if arch_update becomes True, test_inherit_specific
fails)
Fuzzy search for jsonb translated fields has been adapted in the case of
website. It may require some refactoring later.
Purpose of this commit is to add some test about MailThread helpers built on
top of ``message_post`` / ``composer`` (log, post with view, ...). Some tests
about batch are also added.
Some performance tests are also added for those helpers.
Counters are updated. Note that they did not change, it is just an update
based on current master counters.
Task-2710804 (MailThread Api Cleaning)
closesodoo/odoo#100184
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Adapt the activity widget test to use vanilla js instead of JQuery.
Moreover, selectors have been adapted to rely less on the DOM structure
and more on significant class names.
closesodoo/odoo#99924
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this PR, any fail during the QUnit test suite would have failed
the activity widget test. This is due to the fact that this test was
relying on the activity table to be the only table present in the
document. This issue is that QUnit is also using table to display
failed tests. Thus, the activity widget test was looking in the wrong
table to find its elements.
This commit fixes the issue by ensuring the test is actually targeting
the right table that is, the one inside the activity view.
Part-of: odoo/odoo#99924
This change allows for adding and removing followers from threads
by directly setting the message_partner_ids field of threads.
This enables the use of many2many_tags to add followers to a thread.
Task-2804888
closesodoo/odoo#95645
Related: odoo/enterprise#29284
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Make mail_notification_layout as the default mail template and remove
message_notification_email. We now only have 2 main notification mail layout
templates (outside of a light one): the default one and one that inherits from
it to only change the signature to the responsible instead of the author one.
In this operation the layout of message_notification_email has been integrated
in mail_notification_layout to support outlook mail client for which
message_notification_email has just been reworked (odoo/odoo#92847).
Technical note: we have integrated the "internal communication" banner from
"message_notification_email" into the new default template
"mail_notification_layout" which cause one added query in the test for querying
the flag internal from mail.message.subtype.
Task-2801600
Part-of: odoo/odoo#88466
"mail_notification_paynow" mail template layout has been renamed to
"mail_notification_responsible_signature_layout" as it now only differ by the
signature. It allows to use it more widely.
Task-2801600
Part-of: odoo/odoo#88466
Ease the understanding of the notifications sent when users are assigned to an
activity or a model (task, lead, ...).
Technical note:
- the customization of data sent to the email layout template (here subtitles)
should be done by overriding
mail_thread._notify_by_email_prepare_rendering_context on the model.
But in this case, we send an activity (ex.: todo) for a model (ex.: crm.lead)
which involves 2 models. Data from both models must be sent to the template
layout. To solve this problem an optional parameter to
mail_thread.message_notify has been added: subtitles. This allows the
caller which knows about the 2 models to set the values for subtitles for
the template.
- mail_activity._render_notify_header has been added to render the subject and
subtitles using the language of the recipients through the context lang
variable.
- a generic mail notification template has been added and the specific
mail_notification_paynow has been derived from it as the only change is the
handling of the signature.
Task-2801600
Part-of: odoo/odoo#88466
- Remove `_default_log_exceptions` of our `Cursor` class (unused except
in one test)
- Deprecated `serialized` args of `__init__` (Cursor class) and
`cursor()` (of Connection class), our cursor is always serialized.
- Remove `sql_log` attribute of Cursor class and replace it with
appropriate code to do the same stuff dynamically.
- Simplify some code
- Update some docstring
- Clean import
task-2766494
closesodoo/odoo#85078
Signed-off-by: Rémy Voet <ryv@odoo.com>
When creating records with default keys in context those are currently
propagated through the whole call chain until message creation. However
default keys are meant to be used for the record creation, not its logs
or messages.
A protection against default_child_ids already exists. However better
remove all context keys by using a clean context.
Closesodoo/odoo#93797closesodoo/odoo#99670
X-original-commit: 421ee12a099220cb43f3c3f0bf8d51586e687a28
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*: im_livechat, website_livechat
Access right should be based on channel type and membership instead.
Chat always private, group always private, channel private should
disapear and be a group instead (migration needed), and other channel
always public (but they can still be further restricted with
the "allowed groups" feature)
task-2632861
closesodoo/odoo#90415
Related: odoo/enterprise#30980
Related: odoo/upgrade#3850
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Some differences between community / enterprise seems to have vanished.
Task-2710804 (Mail: Clean MailThread API)
closesodoo/odoo#99566
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Not entirely sure about TestAllocationRights. For TestEsEdiCommon
issue is quite obviously that it's inherited by tests which are
external, so when the `post_install_l10n` tag gets applied those tests
get run during "normal" l10n and they break.
closesodoo/odoo#98814
Related: odoo/enterprise#30825
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Update counters after all previous performance commits. It is done as a single
update due to frequent conflicts and difficulty to keep updated counters for
each commit separately.
Task-2883589 (Activity performance and cleaning)
Part-of: odoo/odoo#93682
Purpose
=======
Currently, only email sending can be scheduled with the `scheduled_date` field
defined on on <mail.mail>. It's not possible to delay the sending of
notifications.
We want to be able to delay the sending of the emails, but also the inbox
and bus bus notifications.
Technical
=========
For that purpose, we created a new model which stores the message we need to
notify with the scheduled date. When a scheduled_datetime is given we skip the
notification process. Instead an entry in that new model is created. A cron
regularly polls the scheduled message and launch the notification process on
messages that are ready to be sent.
Task-2207626 (Rating: Delay rating notification to ease feedback)
Part-of: odoo/odoo#95623
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Purpose of this commit is to correctly generate and support scheduled date
defined on template when using ``send_mail`` tool that send emails directly
from a MailTemplate.
It uses the parsing tool method defined on mail.mail in order to have a
datetime localized in UTC then set timezone agnostic as expected by the
ORM.
Task-2826699 (Mail: use datetime for scheduled_date mail field instead of char)
Part-of: odoo/odoo#95623
Purpose
=======
Move the code which updates the mail message from the message model to mail
thread. Most other thread methods (like `_message_update_content_after_hook`)
are defined at record model level. It makes sense to delegate the update to
documents and not to the message. Message is a low-level technical object
that should not really hold business code.
While modifying this code, an update is done in the update content. We now
also allow to update the body without removing all attachments.
Finally tests are added as this feature was added without really testing
model code.
Task-2207626 (Rating: Delay rating notification to ease feedback)
Part-of: odoo/odoo#95623
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Purpose
=======
Historically, we use a char field on the <mail.mail> to match the field type
on the <mail.template>. But even it's useful to have a char field on the mail
template (which can contains QWeb code or Jinja previously to Odoo 15.0) it is
not that useful for the <mail.mail> to keep this char type, because the value
is already rendered. Moreover this forces to have some code convert and store
datetime values using the standard format and in UTC.
We now correctly use a datetime field, as all other fields of that kind in
Odoo.
Task-2826699 (Mail: use datetime for scheduled_date mail field instead of char)
Prepares Task-2207626 (Rating: Delay rating notification to ease feedback)
Part-of: odoo/odoo#95623
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Before this commit, when we open activity view and click on schedule
activity >> select a record there is a trackback due to the
invalid default_res_id passed in context.
So in this commit, fixes the issue by passing the valid res_id in
instead of object with id and display_name.
task-2927335
closesodoo/odoo#96999
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce:
1.) Create a custom email domain and incoming email server on a database, set the
Actions to Perform on Incoming Mails to Create a new record: Helpdesk Ticket.
2.) Set an email alias for a Helpdesk team, set the assignment method to
balanced/random, assign some users to the team.
3.) Set another email address to forward emails to the alias for the Helpdesk team.
4.) Emails received directly by the email alias will create tickets and assign
properly, emails that are forwarded to the email alias will fall back on assignment
defaults.
Explanation:
When we get the "Delivered-To" field for the message dictionnary we use
decode_message_header and the message.get_all() function, this function
returns a list with two addresses but it is transformed back into a string
in decode_message_header with a space as separator. This create an issue
when we use email_split_and_format on this string as it uses
email.utils.getaddresses that expects a list of headers field or a text
where addresses are separated with a comma instead of a string with the
header fields separated by " ". Because of that getaddresses fails to get
the right addresses and the recipients field of the message dictionnary is
missing the right address. Hence when we check if the alias is in this
values it does not find it and use the default fall back.
Solution:
To solve the issue we set the separator as a comma in decode_message_header.
opw-2917543
closesodoo/odoo#98761
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* = calendar, im_livechat, rating, snailmail, test_discuss_full, test_mail,
website_livechat
Distinction between "replace" and "insert-and-replace" can be guessed based on
the type of the provided data.
task-2957295
closesodoo/odoo#98404
Related: odoo/enterprise#30580
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
PURPOSE
Have more reliable tests.
Better spot side effects coming from sub addons.
Lessen non deterministic counters due to local db.
SPECIFICATIONS
Make crm, event and mail performance tests post install.
Update query counters with
* local values (install module only with enterprise activated);
* community / enterprise runbots (if value is different);
* some notes on non deterministic issue if known;
Task-2925606
closesodoo/odoo#96446
Related: odoo/enterprise#29726
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Some fields in composer model allows to control generated messages or emails
values. However they are not available in the form view. In this commit we
add them in form view as invisible, as a first step towards cleaning the
composer code and usage.
Next step will be to cleanup composer code to remove the onchange based on
template and have real computed fields. Those will require fields to be
available in views so adding them is a necessary first step.
Some tests are added to see the usage and purpose of some fields. This helps
having a better code coverage.
Query counters update when using the Form tool
* adding subtype_id: 2 queries
* adding author_id: 1 query
Task-2816845
Prepares Task-2088884
Part-of: odoo/odoo#98287
When sending a mass mail through the composer, if the field ``reply_to`` had to
fall back to being ``email_from``, reply_to would take the value of the template
syntax instead of the rendered value.
This is notably the case when mass-mailing invoices through the accounting app.
Resulting in reply_to fields such as: '{{user.email}}'
On some mail clients (including mailhog), this could also result in template
syntax being shown as part of the subject or sender field.
This commit fixes that by correctly taking the rendered value of 'email_from'
Task-2816845
X-original-commit: e320b852e8f1958ac3dccaa5333420bb7b8d8f3d
Part-of: odoo/odoo#98287
FWD-PORT: updated to new test files, and tests are more in-depth since v14
When sending a mass mail through the composer, if the field ``reply_to`` had to
fall back to being ``email_from``, reply_to would take the value of the template
syntax instead of the rendered value.
This is notably the case when mass-mailing invoices through the accounting app.
Resulting in reply_to fields such as: '{{user.email}}'
On some mail clients (including mailhog), this could also result in template
syntax being shown as part of the subject or sender field.
Task-2816845
X-original-commit: b87df6664908615bdf57bf16e239a10c3f7bf89b
Part-of: odoo/odoo#98287
Currently only an email action based on template exists in server actions when
having mail app installed. It basically sends an email based on a mail template.
However being able to post a message on record is also useful. Instead of
sending emails it post on a document as a comment or as a note, like what
users can do using the chatter. Notification flow for those cases is the
classic from post: followers, specified partners, Inbox/Email, ...
Task-2613245 (Server actions mail update / cleaning)
Closes#45640
Part-of: odoo/odoo#75906
Current behavior
Starred messages counter takes into account the starred messages of a private
channels even if we no longer have access to this channel. Happens with deleted
messages too.
Steps channels
- Install Discuss
- Create a Private Channel and invite Marc Demo to join it
then send him a message
- *As Marc Demo*, star the message then leave the channel
-> Starred counter still shows 1
Steps for deleted messages
- Join the private channel again
- Delete the starred message (with Mitchell Admin)
-> Starred counter still shows 1 for Marc Demo
Reasons
Starred message count is computed by a raw sql [1] which only counts partner's
occurrences without taking into account the message's state and/or the
associated channel.
Side records (stars, notifications) are not removed when emptying a message
content [2].
With changes
- It doesn't take into account messages from a private channel which we no
longer have access to by doing a search on mail.message instead of doing it
in SQL (which filters out invisible messages);
- It correctly voids side records when emptying messages;
Side effects
This somehow raises number of queries because we now check access on messages
and records. However this is necessary as bypassing ACLs means unreachable
notifications or stars.
OPW-2742092
Task-2813738
[1] : https://github.com/odoo/odoo/blob/2c1c6b1373c238216fda1e2d9d2f00b5d16c8ca3/addons/mail/models/res_partner.py#L49-L51
[2] : 776d1ee08bclosesodoo/odoo#97974
X-original-commit: b1e8f7d97e3a1fa624436d2dd6801bf5fe7d19aa
Related: odoo/enterprise#30415
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Alexandre Kühn