Send a message using the popup editor.
Drag and drop an image into the message content.
It will create an attachment for the inlined image.
To generate the values for the attachment, a regex is used to parse the content.
Besides summoning Eldritch abominations, it didnt't take into account the
original filename, whereas the default one (image) would have no extension.
We extend the regex to capture the filename and use it.
opw 1903194
closesodoo/odoo#28527
Send a message using the popup editor.
Drag and drop an image into the message content.
It will create an attachment for the inlined image.
However it did give a res_model value of mail.message but no res_id;
add_missing_default_value would fill in the res_id from the _context, which is
not the mail_message but the current object on which it applies
(e.g. helpdesk.ticket).
We put the correct res_model along with the res_id.
opw 1903194
closesodoo/odoo#28526
- When fetching messages (e.g. opening discuss), we do not check if the
model associated to a message is accessible for the current user.
This could result to access rights error messages when trying to read the
main attachment of the associated record.
To avoid to triggers this errors, we first check if the current user
has read access to the specific model, if so we try to read the
record's main attachment.
closesodoo/odoo#29025
When a record inaccessible by the user is linked
to a message in a channel accessible to the user,
Avoid to raise an access error due to this linked record.
Also need an aditional query in test query_count.
closesodoo/odoo#28312
Before this commit, when a non-moderator user posts a message in a
moderated channel and refreshes the page, he could no longer see his
messages that are pending moderation.
This commit adapts the business code to changes introduced by
the parent commit in order to keep the same behaviour as before.
All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.
The combined domain for moderated messages used to trigger a complex
database query with two OR conditions on the mail_message table.
Unfortunately PostgreSQL seems to be unable to optimize this with
indexes, or to detect that one of the conditions is void (included `AND
FALSE`). On large mail_message tables, this significantly slows down
calls to message_fetch, e.g. 6s instead of ~70ms, while returning the
same results.
As a workaround, move the logic for generating the moderation domain to
the server side, where it can be:
- optimized out when the user is not a moderator
- split into 2 distinct DB queries in order to avoid the pathological
case
After this change, calls to message_fetch with and without messages
to moderate execute in respectively ~50ms and ~150ms, instead of 6s, in
a test database with 25 million messages.
The modified message_fetch signature is backwards-compatible.
+ modified mock server used for the tests, which unfortunately
duplicates most of the business logic.
Other operators can only cause nonsensical results, while causing
useless slow queries. This is only really meant as a shortcut for
getting messages to moderate.
This is done by adding a new field on mail.thread objects and setting it when posting a message with attachments on a model inheriting from mail.thread.
Was part of PR #26740
Was part of task #1880089
We need to know if a notification is in failure by
displaying the red envelope in even if all partner are inactive.
This commit also fix the filter in order to display notification
of all active partners if there is an exception.
The search on message_has_error (used when clicking on a failure notification)
was displaying the failure of all users making it difficult to find your
own mail failure. This fix solve the problem by adding a criteria on message
author_id.
- When trying to fetch notifications for failed mail delivery, the code
doesn't check if the partner is active or not.
If the partner is archived, then it tries to access its information on
a dict that doesn't contains them and crashes.
Purpose
=======
Sometimes we could want to send a notification to the author too.
Like in the onboarding bars, where we send a sample invoice to the administrator.
He's the author of the message, but the goal is to send him an email to check the
full process when sending a sales order/invoice by email to a customer.
Specification
=============
For that purpose, if a key 'mail_notify_author' is set on the context when
sending the email, then notify the mail author.
This commit is the counter-part of an enteprise commit introducing
the Documents app.
Here is a summary of what has been done:
- tweak unlink of ir_attachment to prevent unlink recursivity
(when attachments are attached to ir_attachments)
- improve ir_attachment kanban view
- add several arguments to binary_content controller:
- 'force_ext': to force the extension in the filename, base on
mimetype
- 'share_token' and 'share_id': to autorize download from a
share link
- add 'thumbnail' field on ir_attachment to optimize Kanban view
- add 'upper_limit' argument to image to allow to bypass the
500*500 size limit
- DocumentViewer now handles text files
More information available on task 1853490
Co-authored-by: Pierre Paridans <app@odoo.com>
Co-authored-by: sri-odoo <sri@odoo.com>
Co-authored-by: ThanhDodeurOdoo <tso@odoo.com>
Purpose of this commit is to avoid browsing and prefetching data about
recipients when notifying a message to partners and channels. Mail message
_notify computes all necessary data in a single query. This commit allow
to re-use this data by propagating it through the call chain.
Addons inheriting from classification methods used when sending notification
emails are updated accordingly to the API and data update.
This commit is linked to task ID 47934 and PR #24033. No functional change
should occur with this commit.
This commit cleans code about sending email notification to recipients.
Purpose of this code is to prepare notification emails, group recipients
and finally send emails. In this commit we clean and optimize a bit by
* propagating some additional parameter to simplify code, like record
on which the notification process runs;
* inlining some code currently located in sub-methods. It eases code
understanding as there are less code jumps. As those methods are not
inherited inlining them can be done;
* simplifying a bit notification emails preparation and computation;
It allows to save a few query by avoiding to fetch and browse again some
data that were already computed.
This commit is linked to task ID 47934 and PR #24033. No functional change
should occur with this commit.
In this commit we update _notify method of mail.message to fetch most data
related to notification process in a single query. Indeed posting a
message can be a costly process, especially when involving several partners,
channels, depending on their notification status, user groups, ... Most
of the required data can be fetched in a single hand-tuned query.
Purpose is to lessen query count. Side effect of this commit is that code
is less recordset based and therefore more low-level. It is also harder to
customize the behavior through inheritance as it implies rewriting a bit
more of code.
This query is located in a private method on follower model. It takes
parameters allowing to either fetch data related to followers of a given
subtype, either related to some partners and channels. First use case is
related to the process of posting a message with a subtype that triggers
notification of followers. Second use case is related to notifying some
specific partners or channels of a given message. It takes notably into
consideration internal subtypes and active field of partners, allowing to
correctly handle corner case for deactivated followers and portal / share
partners.
Notification process is divided into two steps. First one is to compute
recipient data. Second one is to apply the result of this computation and
call the various notification mechanisms accordingly. Doing so allows to
easily re-call notification process or compute some data differently
if necessary.
API of notification methods is updated to allow passing notably the values
used to create the newly-posted message. It allows in some simple case to
avoid browsing message and partners when no notification is necessary. It
saves some queries in simple case like posting messages with specific
subtypes not often followed or logging notes without mentioning people.
This commit allows to save a few queries on several performance tests as
indicated by updated performance counters. Future commits will gradually
propagate the use of this data to further lessen query count.
This commit is linked to task ID 47934 and PR #24033. No functional change
should occur with this commit.
- Email generated from mass mailing will have its own layout with internal css.
- strip_classes is removed from mail_message because mail client are now supporting
internal stylesheet. we need it for make mail responsive.
mail: manually removed classes from incoming mail body
Because we removed strip_classes from mail message body field because we want to
allow classes in outgoing mail to make it responsive but classes are not removed
from incoming mails so here we manually removed classes from incoming mail.
opw-1836556
Purpose of this commit is to speedup tracking values creation by manually
creating them using the newly-introduced multi create. As tracking values
creation is already done manually as sudo when creating mail message we
just update the code to directly insert them as multi.
This commit is linked to task ID 1870656 and PR #26068. No functional change
should occur with this commit.
Only the add_sign from notif_values is usefull for a resend. We can consider
that a mail on resend can be delete in every case, and we can find the
model_description from model since a resend can only be performed on
message linked to a model.
The other notif_values are now parameter in order to ease the understanding
of what can transit through this flow.
Task: #1860054
PR: #25622
Steps to reproduce the bug:
- Go to Odoo on Safari browser
- Go to CRM > Operations > Manufacturing orders
- Select a MO and log a note on it with a video attachment
- Try to watch the video
Bug: it's not possible to watch the video
HTTP servers hosting media files for iOS must support byte-range requests, which iOS
uses to perform random access in media playback. (Byte-range support is also
known as content-range or partial-range support.)
Odoo server doesn't support partial requests with accept-ranges
opw:1857873
When a mail is in failure state, a red envelope appears next to the message
in a thread but it was difficult to send the mail again.
This tasks will allow users to send mail again easily, or mark notification
as cancelled if the user want to ignore this failure.
A notification will appear in sender systray while mail are in failure.
Task: #46158
PR: #24628
Purpose of this commit is to allow moderation on incoming messages in
discussion channels. On some channels on which moderation is required
messages should be in a pending moderation stage. Moderators can accept
or refuse messages as well as always allow or ban messages coming from
a given set of emails.
Channels now have an option to be moderated. Moderators can be added on
channels. They have access to a specific UI in Discuss to see and take
action on messages waiting for moderation.
Concerning mail.thread message that are pending moderation are not notified.
It means nobody receives a notification about them. Moderation process calls
the notification once the message is validated.
Various features included in this commit :
* a model is added to store the decision about emails, allow or ban;
* access rights are updated so that only moderators can modify moderation
fields on message;
* specific bus notifications are send to moderated people as well as to
moderators on incoming emails as well as when a decision is taken;
* options are added on channels to send explanations to moderated emails;
* options are added on channels to write and send guidelines explaining
why and how moderation is performed;
* a reminder is send daily to moderators with remaining messages to moderate;
* discuss UI is adapted and a new channel is added below Inbox and Starred
giving access to moderation tools;
* chanenl UI is adapted allowing to moderate directly inside channels;
This commit is linked to task ID 29521. Closes#21921.
This is a better implementation of 19fb650863. It seems we did not
see the fix was inside a loop meaning not really optimized when thinking about
Inbox fetching a lot of messages.
Previously to this commit needaction used by JS was not taking into account
read notifications. It means notably Inbox counter could be higher than
expected as taking into account read messages while Inbox displays only
unread messages. This commit fixes that by checking notification state when
giving needaction_partner_ids to message_format result.
This fix has a small impact on performances as message_format is used in
notification process for chat or push. A better implementation of message
format and its postprocess could probably lessen this fix impact. As we
target stable version we avoid rewriting other part of the code. Optimization
will be done in development version.
Related to task ID 1841243. This is a manual forward port of commit 69714fbeee
done in saas-11.2.
Previously to this commit needaction used by JS was not taking into account
read notifications. It means notably Inbox counter could be higher than
expected as taking into account read messages while Inbox displays only
unread messages. This commit fixes that by checking notification state when
giving needaction_partner_ids to message_format result.
This fix has a small impact on performances as message_format is used in
notification process for chat or push. A better implementation of message
format and its postprocess could probably lessen this fix impact. As we
target stable version we avoid rewriting other part of the code. Optimization
will be done in development version.
Related to task ID 1841243. This is a manual forward-port of commit 69714fbeee
done in saas-11.2.
Previously to this commit needaction used by JS was not taking into account
read notifications. It means notably Inbox counter could be higher than
expected as taking into account read messages while Inbox displays only
unread messages. This commit fixes that by checking notification state when
giving needaction_partner_ids to message_format result.
This fix has a small impact on performances as message_format is used in
notification process for chat or push. A better implementation of message
format and its postprocess could probably lessen this fix impact. As we
target stable version we avoid rewriting other part of the code. Optimization
will be done in development version.
Related to task ID 1841243. This is a manual backport of commit 69714fbeee
done in saas-11.2.
Previously to this commit needaction used by JS was not taking into account
read notifications. It means notably Inbox counter could be higher than
expected as taking into account read messages while Inbox displays only
unread messages. This commit fixes that by checking notification state when
giving needaction_partner_ids to message_format result.
This fix has a small impact on performances as message_format is used in
notification process for chat or push. A better implementation of message
format and its postprocess could probably lessen this fix impact. As we
target stable version we avoid rewriting other part of the code. Optimization
will be done in development version.
Related to task ID 1841243.
mail.thread mixing class defines several methods used in notification process
that are not specific to mail.thread enabled models. It means some models
could override it while some other models do not even have a direct access
to that method.
When calling those methods we have to manually check for method being
available on a record or call a default implementation from mail.thread
even if the model does not inherit from the mixin.
In this commit we propose to hide this check in generic wrappers located
in mail.thread class. It checks for method existence on record and call
the model-specific implementation or falls back on standard behavior. It
allows to be sure the right method is called.
Functionally behavior should stay globally the same. However when updating
some addons code has been updated. Previous code could lead to records not
having correct alias which should not be the case anymore. This commit is
linked to task ID 47934.
User notifications are defined as
* notes;
* pushed to user Inbox or email through classic notification process;
* not linked to any document, meaning model and res_id are void;
When pushed in user's Inbox they are currently displayed with a gray
background like all notes. However UX experts think it should use a white
background to be easier to spot in chatter. This commit makes it work.
From now on discussion and user's notifications are displayed using a white
background. This commit is related to task ID 1829872.
Christophe Simonis