Steps to reproduce:
On Odoo:
- Install `Documents` module
- Go to `Settings` and set a Custom Email Server(ex. `mydomain.com`)
- Ensure an alias exist for the model `document.document` with `inbox-financial` as alias name
In mail client:
- Send a mail with an image in the body to the following email: inbox-financial@mydomain.com
Issue:
Mail not received (traceback in logs)
Cause:
Since we use the email alias `inbox-financial`, we process the mail
through the `document.document` model where we have an override of the
`_message_post_after_hook` method that is called after that the
`msg_values` values are post-processed and where we do another
message_post() for the new document create for the attachment (in
this case, an image).
https://github.com/odoo/enterprise/blob/2c3596e4e18c201809558d3ea878b141e366a027/documents/models/document.py#L305
During the parsing, the mail values are updated through the
`_process_attachments_for_post` method:
https://github.com/odoo/odoo/blob/6c0d2d7a9d44459f3e09a38bd80ef9b018e8c946/addons/mail/models/mail_thread.py#L1881-L1904
On posting the first time, the original type of the `body` value is a
`str`, but the post-processed value (because there is some CIDS in the
body) is of type `bytes` (because using `encoding='UTF-8'` with
`lxml.html.tostring`).
https://github.com/odoo/odoo/blob/510a997017a9cbe14522a0013a578f6d1d9b257a/addons/mail/models/mail_thread.py#L2209
Then in the `_message_post_after_hook` we call post again on the
newly created document record by using post-processed value of body
who is of type `bytes`.
On posting the second time (for the document record), the `body`
value is of type `bytes` and when checking if the body is empty with
`is_html_empty` that received a string as param, an error is
raised.
Solution:
Use `encoding='unicode'` to return a string instead of bytes.
https://lxml.de/api/lxml.etree-module.html#tostring
opw-3273583
closesodoo/odoo#135172
X-original-commit: 394031561179af6930eb71fcf7017f8f9d285aed
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
When calling track_prepare, an important part of the logic is getting
description in fields_get. We actually don't need the description,
fields_get is mainly use here to check for groups, but the dictionnary
is immediately transformed to a set making values irrelevant.
The same optimisation is done in _message_track, usefull to avoid an
additionnal query in test_recurring_order_creation_perf, because of a
value not in cache.
closesodoo/odoo#134689
X-original-commit: a7e7f90531a21af99a4c95abb829f8f6de94f68a
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
In this commit, we moved all features related to the PWA and the PWA
itself to the community.
This includes:
* PWA
* Web Push Notification
* VCARD
Note from original commits:
===========================
PWA (part 1)
------------
This commit adds a ServiceWorker to complement the WebManifest to
complete the setup of the backend as a Progressive Web App.
More precisely, it adds the route, registration and the most basic
ServiceWorker to allow the backend to be recognized as an installable
PWA.
References:
- https://web.dev/install-criteria/
- https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Installable_PWAs
- https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers
Task ID: 3063485
PWA (part 2)
------------
This commit adds a WebManifest as a first step toward setuping the
backend as a Progressive Web App.
In a nutshell:
- the web app's name is configurable through a config parameter
(available in the Settings, in debug); defaulting to "Odoo".
- the web app's icon has been revamped to accommodate the required sizes;
also its design matches the one from the Android app.
- "theme-color" is used to color part of the browser/system UI to match
Enterprise brand color; also supports the dark mode.
References:
- https://web.dev/learn/pwa/web-app-manifest/
- https://web.dev/install-criteria/
- https://developer.mozilla.org/en-US/docs/Web/Manifest
Task ID: 3063485
PWA shortcuts
-------------
The main goal of this commit is like we did inside the `Android Odoo
Mobile App`, allowing users to have some Odoo application shortcuts.
We added the following apps in the key `shortcuts` on `web.manifest` in
these orders: `Discuss`, `CRM`, `Project`, `To-Do` (old `Notes`).
Links:
- https://w3c.github.io/manifest/#shortcuts-member
- https://developer.mozilla.org/en-US/docs/Web/Manifest/shortcuts
Task ID: 3123607
Offline mode
------------
This commit introduces a way to notify the user that he's "offline"
(aka. cannot reach its Odoo server) and that Odoo doesn't work in a
graceful way in this circumstance.
To do so, the Service-Worker will return the response of the
´web/offline´ route, which is cached at its setup.
Note: this screen is only show when launched while "offline" and fails
to load the requested page. It does not "interrupt" the WebClient to
show this screen when the connection drops off (cf. not a replacement
for the existing notification).
Task ID: 3203639
WebPush
-------
WebPush allows sending data to the user browser/app(PWA) even when
tab/app is closed. Web push is a "constant" link between the
ServiceWorker of browser/app and a WebPush server.
Note that each browser has its own custom WebPush server.
e.g.:
Chrome: https://fcm.googleapis.com/
Firefox: https://updates.push.services.mozilla.com/
Safari: https://web.push.apple.com/
Edge: https://wns2-ln2p.notify.windows.com/
WebPush introduces some cryptographic notion to ensure some the
reliability of the data sent:
VAPID: "Voluntary Application Server Identification" is the standard
used to generate the public and the private to sign the message
between the browser and the WebPush server
JWT: "JSON Web Token" is the standard used to sign the payload to the
WebPush server
ECE: "Encrypted Content-Encoding" is the standard used by WebPush to
encrypt the data of the payload to avoid sending RAW data
outside trusted network.
Simplified steps how to WebPush works:
The Javascript code of a web page subscribes to the WebPush server
(using the VAPID key generated at mail_entreprise install).
The WebPush server replay with a subscription (and some other info
like the unique URL endpoint per subscription where to send a
notification)
The application (odoo-bin in our case) sends a post request to the
WebPush server using the specific URL endpoint of the user (using JWT
and ECE).
The WebPush server sends back to the browser the encrypted payload.
The browser decrypts the payload and sends it to the ServiceWorker
linked to the subscription.
Here is a Sequence diagram of all interactions to process a web push
notification.
In Odoo, we use WebPush to send Notification to the user.
This commit aims to have a parity with the Android/iOS Mobile App at
the notification level.
Notes:
There are some ways to encrypt (ECE) the message for WebPush:
AESGCM128: this is a draft
AESGCM: very well documented
AES128GCM: RFC8188 Standard encoding
We implement only the RFC one as it is the only one implemented in all
major updated browsers (Chrome, Firefox, Safari, Edge, ...)
You need to allow the desktop "Notification" and "Push" inside your
browser. For iOS Devices, it only works on iOS 16.4+ and it's requiring
Odoo to first be added to the Home Screen. It's delivered silently,
meaning no sound, vibration, haptics or screen wake.
Note:
Notifications are sent directly if there are less than five
notifications, otherwise we use a cron triggered immediately.
Also, we have changed the value of the "QueryCount" as mail_enterprise
executes a new query to search the devices associated with the partner.
We have added a "try/except" for any Exception before the
push_to_end_point method as we want to avoid blocking a normal flow
just for a not mandatory push notification if something happens during
the push to the endpoint.
See: odoo/enterprise@d0ae70103d
Links:
https://www.rfc-editor.org/rfc/rfc8030https://www.rfc-editor.org/rfc/rfc8188https://www.rfc-editor.org/rfc/rfc8291https://www.rfc-editor.org/rfc/rfc8292https://w3c.github.io/push-api/index.htmlhttps://autopush.readthedocs.io/en/latest/http.htmlhttps://web.dev/push-notifications-web-push-protocol/https://github.com/web-push-libs/encrypted-content-encodinghttps://github.com/web-push-libs/pywebpushhttps://github.com/web-push-libs/vapidhttps://caniuse.com/push-api
Task ID: 3123678
VCARD
-----
In the process of replacing the native methods exposed in the mobile
apps, this commit implements the download of a vCard containing a
partner's information.
By using this standard format, both regular web users and mobile ones
are now able to save the partner's details to use them with their usual
address book software.
On a mobile device, the actual import of those informations is delegated
to the operating system.
References:
- https://datatracker.ietf.org/doc/html/rfc6350
- https://en.wikipedia.org/wiki/VCard
- https://github.com/eventable/vobject#vcards
Task ID: 2583916
===========
End of note
===========
Task ID: 3478014
closesodoo/odoo#133560
Related: odoo/enterprise#46530
Related: odoo/upgrade#5086
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Co-authored-by: Romeo Fragomeli <rfr@odoo.com>
Co-authored-by: Romain Estievenart <res@odoo.com>
Co-authored-by: Pierre Paridans <app@odoo.com>
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
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS
Tool method '_mail_find_partner_from_emails' that searches for partners based
on email is improved to support multi-emails input. Instead of skipping
multi-email (current behavior of 'email_normalize') we now consider first
found email in the input.
It is used notably to match incoming email / partners or suggest recipients
in Chatter.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@e0582b9e1f
Part-of: odoo/odoo#134934
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS
When possible, use 'email_formatted' field on partner, instead of calling
'format_addr'. That way management of corner case input (multi emails and
double encapsulation) is managed by the computed field itself.
When 'format_addr' has to be used, ensure email part is normalized to avoid
formatting issues.
Also use tools to extract emails instead of 'email_re' regex when possible.
That way all code extracting and managing emails go through the same stack.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@1c06014531
Part-of: odoo/odoo#134934
Add 'id' in partner ordering, to be sure searching on duplicated partners is
deterministic.
In mail, use standard ordering when searching on users to be deterministic.
As ordering on users is based on name then login which is unique, this is a
safe ordering and can be used as it.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@1e6d50a141
Part-of: odoo/odoo#134934
In this commit we allow to give 'partner_ids' when using '_message_log'.
This allows to link a message to recipients but those are not notified
in any way.
Main purpose is to link a message which has a side effect to the main record
customer. First usage will be in WhatsApp implementation to link a sent
WhatsApp to a recipient, easing finding it back when receiving replies.
Task-2377154 (Add WhatsApp Support)
Part-of: odoo/odoo#134377
To reproduce
============
- login as Mitchell Admin
- change the email of a portal user, ex: Joel Willis, to the same email
as Mitchell Admin. Do this through the Contacts App
- always connected as Mitchell Admin, create a sale order and send it by
email to client, in chatter the sender will be Joel Willis
Problem
=======
when setting the author, `_mail_find_partner_from_emails` is called, when searching
for users with the given eamil, two results are found and the first one
is taken as author
Solution
========
give the priority to the current user when it matches the given conditions
opw-3455520
closesodoo/odoo#134609
X-original-commit: b4a9095497fb77e6963103fa2a27d20e00172ea1
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
Before this commit, recipient list in chatter when using composer
in "Send message" mode where listing emails of all followers, instead
of only subscribers of "Send message" (= `mail.mt_comment`).
This commit solves this issue by loading and showing followers
that are recipients in this list. Because this feature and follower
list lazy-load some data, they need to manage they own list for
the "load-more" aspect. That's why the diff shows some duplicated
code as with `followers` field of JS thread model.
closesodoo/odoo#134225
X-original-commit: ba43502b22f8f00e7a2318b341302b809e7129dc
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Use the operator inselect instead of in with a read() before it.
This ensures a subquery is used instead of two separate queries.
When you have a user that is following thousands of tasks and the
security filter depends on this search, all queries are very slow. Using
a subquery prevents from reading these ids and sending back a very long
query to the database.
closesodoo/odoo#133273
X-original-commit: 7f9e98c0d7441b2103df0b89183b6949f3bc9b69
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Some external tools send email as pure html (no multipart) and when
parsing such email we ends up having the raw HTML as body (text)
This commit ensure we correctly parse and sanitize the body as HTML
for such emails.
closesodoo/odoo#132127
Task-id: 3451889
X-original-commit: a4763d214bfc7b09510226e552f749f9cd95870e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>
Since 69f911d994 it was no longer possible to post an HTML
message via a script. Allow to do it but log a warning to discourage
doing so. Markup object should still be the propoer way to do it.
closesodoo/odoo#130883
X-original-commit: a890db49935813d0794765492c057404592e5977
Related: odoo/documentation#5273
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
[1] introduces an issue when a response is sent to an aliased email.
In that case, it is intended that the message should be created
by the owner of the alias by [2]
Which breaks the assumption of made in the first commit, as the message
is being passively processed by fetchmail.
This causes the owner of the alias to never be notified on reponses
in cases where the message could be an alias update.
i.e. on any model where the alias applies.
Because the responses are assumed to have been authored by the owner.
As we do not actually care who creates the message records
and deciding the alias owner 'created the message' does not
actually make sense.
We make sure messages are created by odoobot even
if the message was sent to an alias address.
[1]: c676ed3ea906e99d27a6116cd77218c5ec95b416
[2]: af80c68ae5
task-3383275
X-original-commit: 96fe37d37c94c3d6f4642bd6c28d13fcd87075b7
Part-of: odoo/odoo#130798
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
Move 'mail' and 'phone_validation' helpers directly at model level, allowing
to rely on those methods in all models instead of only when inheriting from
'mail.thread' or 'mail.thread.phone'.
Those helpers are used to find primary email, phone numbers or customers in
flows involving sending emails or SMS. A default behavior exists that is
generally valid for most models. Method can then be overridden to implement
their own custom behavior.
Future commits will improve them and remove duplicated computation between
mail, phone_validation, mass_mailing and sms modules.
Task-3422449 (Mail, Phone: Move and improve field helpers)
Part-of: odoo/odoo#130468
This commit fixes a really old grammar error in the help message of the
message_needaction_counter field.
Before this commit: “Number of messages which requires an action”
After: “Number of messages requiring action”
The subject of “require” is “messages”, which is third-person plural, so
it can't take the -s suffix.
closesodoo/odoo#129468
X-original-commit: 0d10cfeaa56d5df23df05f436d353978043f4a71
Related: odoo/enterprise#44509
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
This PR prepares the ground for the one introducing guests
for livechat visitors. Since our SameSite cookie policy
is Lax, the cookie won't be send on unsafe cross site
requests thus another mechanism will be introduced to
retrieve the guest.
This PR abstracts the way the guest is retrieved in order
to ease this transition as much as possible by overriding
the `ir_http._pre_dispatch` method in order to inject the
guest in the context if any.
part of task-3332628
closesodoo/odoo#129039
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, the data of all followers of a chatter were
fetched whenever `mail/thread/data` was called. This route is
called when loading the chatter for the first time, and whenever
the chatter must be reloaded.
When there are at most dozens of followers, it's not a big deal.
However, with thousand of followers, the route `mail/thread/data`
may become quite long, which made chatter barely usable with a
long loading.
This commit fixes the issue by showing only 100 followers at once
when opening the follower menu. When scrolling down the list,
it loads data of more followers.
Task-3293718
closesodoo/odoo#127966
Signed-off-by: Didier Debondt (did) <did@odoo.com>
Steps to reproduce:
- Install CRM and Helpdesk modules (for test purposes)
- Set a custom alias domain (e.g. "mydomain.com")
- Go to CRM > Configuration > Sales Teams
- Check that a team has en email Alias (e.g. "info@mydomain.com")
- Go to Helpdesk > Configuration > Helpdesk Teams
- Check that a team has en email Alias (e.g. "support@mydomain.com")
- Email your instance with the following `to` value:
info@mydomain.com, support@test.com
(notice second email does not match the DB alias domain)
- Go to CRM : A task has been created
- Go to Helpdesk : A ticket has been created
Issue:
The ticket in Helpdesk should not have been created.
Cause:
The message_route method does not check the domain of the email
address before creating the routes.
Solution:
If `mail.catchall.domain.allowed` system parameter is set, filter to
only keep the emails address that match the allowed domains (including
domain set in `mail.catchall.domain` system parameter).
The value of `mail.catchall.domain.allowed` system parameter should
be a comma separated list of domains. e.g. `example.com,example.org`
opw-3150972
closesodoo/odoo#128346
X-original-commit: 5b73428104789433fd65431f7631a2e9eb863b2f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Backport of `_get_guest_from_context`.
Prevent crash when unexpected (not recordset) values are in the context.
Ensure the mere existence of a value (example integer) does not lead to
executing flows where an actual guest is expected.
task-2819597
closesodoo/odoo#127831
X-original-commit: 3d1890e88b99f059377d8b227b56d77798157397
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, only logged notes could be edited in chatter.
With this commit, messages sent with "Send message" are also
editable.
Task-3380465
closesodoo/odoo#125939
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Follow-up of https://github.com/odoo/odoo/pull/120002
Commit above made a a structural change of code that
should not have changed the functional behaviour of
chatter.
In consideration of reducing query count footprint,
it replaced a `browse().exists()` by `search()`, as
`exists()` always perform a query whereas `search()`
may rely on cache and skip a query.
However, `search()` filters archived records, so this
change unintentionally removed the possibility to send
messages on archived chatter. Also the performance of
`search()` and `browse().exists()` are pretty much the
same, so the premise of changing it to `search()` seems
wrong.
This commit reverts this part so that this is the exact
same behaviour as before.
closesodoo/odoo#127518
X-original-commit: 43227ad2eaaeba3f6e3e6fae8b84728e0c33c59a
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
- Improve performances, as the ir.rule restricting private partners
visibility is also applied on res.users by inheritance, on each
prefetch.
- Solve the issue of partners set as followers on records (eg: application
form) and then made private, making them impossible to contact via the
chatter.
- Solve the multiple access issues when trying to access the bank
account, or the private address for non HR people like the accountants
forcing the usage of sudo in the business code.
TaskID: 3101400
Before this commit, when editing a message, it was not possible
to add new mentions.
This commit adds the support to add new mentions when editing the
message.
Note that mentions added from editing message won't notify them:
it's only at creation of message that mentioned users are notified.
task-3329714
closesodoo/odoo#126888
X-original-commit: 1fe935d273142064784b9ecff2fff1c34e91064f
Signed-off-by: Alexandre Kühn (aku) <aku@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
When parsing an email containing an xml attachment, the `email` python
module will decode the base64 attachment using the charset or ascii if
the charset is missing.
In some cases, the payload is in UTF-8 but the charset is omitted. This
results in replacement characters for the non ASCII characters.
The solution is to force the charset to UTF-8, since it is a superset of
ASCII that should not be a problem.
NB1: Omitting the charset for text/xml is not recommended. See the RFC
(section 6.4): https://www.ietf.org/rfc/rfc2376.txt
opw-3144519
closesodoo/odoo#126474
X-original-commit: e3a5b46c7b4f5030e165a6d943ec2275aea5d583
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
There exists edge case on `reply_model`. when value of
`mail_messages.model` in database is empty then `mail_messages.model`
returns False, hence `reply_model` becomes False which raises
an error because _get_id does not accept a falsy values.
(because query: `SELECT id FROM ir_model WHERE model=false` has to
be run and model is char). Because of the fact that this query never
runs and fails opportunity is lost.
task-3248489
closesodoo/odoo#123488
X-original-commit: 6c0d2d7a9d44459f3e09a38bd80ef9b018e8c946
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
When receiving an email on a mailbox with an alias that triggers the
creation of invoices, 4 bugs could occur.
1. If the xml received contains replacement characters (U+FFFD �), and
the charset of the part of the email is "US-ASCII" the encoding of the
string will fail, preventing the rest of the flow to be completed. Be
more resilient, encode the string and ignores these characters if this
case occurs.
NB: sometimes, the charset is omitted for a Content-type: text/xml. This
is valid but not recommended (see:
https://www.ietf.org/rfc/rfc2376.txt). In this case, the default used is
"US-ASCII". This means that any non-ascii char will be lost (they are
replaced by the replacement character: �, see:
https://github.com/python/cpython/blob/3.10/Lib/email/contentmanager.py#L67)
when decoding the attachment.
2. When the xml attachment is created in Odoo, the mimetype is
'text/plain' (rather than 'application/xml'). Thus, the
`_decode_attachment` needs to be more flexible when guessing the type of
the attachment (to know which function to use to read the content of the
attachment and create the invoice).
3. When creating an invoice from an email with an xml attachment, the
xml is attached as the `message_main_attachment_id`. It's only later on
that the content of the xml is read and we possibly find the PDF in
base64 inside. When creating the PDF attachment, it was not set as the
`message_main_attachment_id`, so the PDF was not rendered on the right
part of the invoice form view. Add a clause to replace the
`message_main_attachment_id` in such a case.
4. When the xml attachment represents a credit note, the move_type of
the invoice created by the email alias needs to be changed. Indeed, the
invoice is created before decoding the attachment, so we can only change
the `move_type` later.
opw-3144519
opw-3149649
closesodoo/odoo#121076
X-original-commit: 1e193a92b9c84e75b958985f8067873b90f686e0
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Allow users to unfollow easily document from the inbox for which he/she doesn't
want to be notified anymore.
When hovering on a follow up message with a related document followed by the
user, the interface displays an action to unfollow it that allows the user to
remove himself/herself as follower of the document. As a result of performing
that action a toast is displayed as a feedback.
Technical note:
The unfollow link is displayed on a message.canUnfollow is true which check
that the thread related to the message is followed by the user.
In order to know if the user follows the record related to the message, we now
transmit with each message the id of the follower table that link the user to
the related record if it follows it. This allows to insert the follower on
client side so that the unfollow action can use the standard mechaism already
developed to unfollow a record.
Unfortunately, that information coudn't be added in the already public method
message_format of mail message because that method is not always called on the
user retreiving the message but also by the one posting message. We didn't want
also to include all followers in the formated message so we rely on additional
method that add that information per partner.
To support unfollowing a document in the inbox no matter the current company,
we have modified message_unsubscribe in mail_thread to allow internal user to
unsubscribe themself without checking any rights. Indeed, some document have
record rule that prevents reading it if the user is not in the right company
(ex. crm.lead) and then was preventing the user to unfollow the document using
that method.
Task-3061864
Part-of: odoo/odoo#107978
Currently some auto_reply templates are internal as a means to prevent
notifying users everytime we send a reply to somebody.
This raises the issue that since responses to internal notifications
are themselves internal notifications, often nobody will be notified of
responses to these automated messages.
We fix this by marking these messages as auto_comments, which will
ensure responses to these messages are
considered non-internal (and thus 'discussions', by default).
task-2834304
closesodoo/odoo#94018
Related: odoo/enterprise#35466
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If a tracked value sent a mail template on creation of a record,
the template was displayed before the original message in the chatter.
We fix this by using precommit hooks similar to those already used for
tracking.
We also update the query count for a couple of tests. This is required
because in those tests the test user is not in the cache when we execute
the precommit hook, which we use to fetch a fallback language early in
the precommit.
Task-2834304
Part-of: odoo/odoo#94018
By this commit, If a user edits the message body or changes
the message attachments, the edited label in the blob,
shows the last edit Info.
Task-2664848
closesodoo/odoo#117896
Related: odoo/enterprise#40208
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
As a bonus, add cross-tab update for current user in chatter.
Part of task-3265211
closesodoo/odoo#120018
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The opportunity is taken to clean the methods to make the override
actually possible.
Part of task-3265211
closesodoo/odoo#119942
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
A new `_track_set_author` method is now available to explicitly set the
author of the tracking messages.
Related Enterprise PR: odoo/enterprise#38986closesodoo/odoo#117073
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
- Configure incoming mail server and set it to create X record
on incoming mails (X can be any model with a chatter)
- Create a CSV file and set the encoding to UTF-16
- Send the CSV file through Gmail to the Odoo instance
- Go to model X and open the created record
- In the chatter, click/download the CSV file
- Open the downloaded file with Geany (or any file editor that can
show the file encoding)
Issue:
The file encoding is not the same as the original file (utf-8 instead
of utf-16).
Working with Outlook.
Cause:
The difference between Outlook and Gmail is that Gmail provides the
charset of the file.
The content of the mail is retrieved using `email` python lib.
The lib will try to retrieve the charset of the file and fallback
on `ASCII` if not available, then return the decode content.
```python
def get_text_content(msg, errors='replace'):
content = msg.get_payload(decode=True)
charset = msg.get_param('charset', 'ASCII')
return content.decode(charset, errors=errors)
```
Example:
content = b'd\x00a\x00,\x00,\x00,\......'
Outlook:
charset = 'ASCII'
return => 'd\x00a\x00,\x00,\x00...'
Gmail:
charset = 'UTF-16LE'
return => 'da,,,,,\n,,,,,\....'
In the post process of the attachment, the content is encoded in
'utf-8' (to then encoded in base64) before creating the attachment
record.
Content encoded to 'utf-8':
Outlook: b'd\x00a\x00,\x00,\x00...'
Gmail: b'da,,,,,\n,,,,,\n....'
Therefore, when writing the file on the disk, the encoding is based
on the binary content.
Solution:
When parsing the mail, add the encoding charset to the `info` variable.
Then, when creating the attachment, use the charset in `info` (or
fallback on 'utf'8' if no charset set) to encode the content.
opw-3089009
closesodoo/odoo#118694
X-original-commit: 2d1b13e68d8bb204ecfe12a9d3db519c4264592c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
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>
With this commit, messages can be pinned on a channel and
chat conversation. There's a new menu listing all pinned
messages on a conversation, and we can jump to these messages
in the current conversation.
As this feature incentives to see older messages, this commit
also adds a "Jump to Present" button when looking at old messages.
closesodoo/odoo#116666
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
While we run cron `Data Merge: Find Duplicate Records` an issue raises because
`data_merge.model` has no method `_message_compute_subject`. Indeed it is
possible to notify on non-thread models but that method is a thread-only
method.
In this commit, we only call `_message_compute_subject` when it's available
in model.
sentry-3947126655
Task-3254379
Part-of: odoo/odoo#117763
RATIONALE
Naming conventions
* content = core message / subject (+ other fields);
* email layout = layouting applied to messages when sent to recipients who
receive notifications by email e.g. access button, ...;
* comment mode / mailing mode: composer main composition mode: posting on
record(s) / sending a mailing on records;
Content situation when using a template to post on a composer
* comment, monorecord mode: choose a template, content is rendered directly
from template side according to 'lang' field definition -> ok;
* comment, multirecord mode / mailing mode: choose a template, content is
the raw content. At post / send, content is rendered and translated if
matching template content -> ok;
Email layout situation when posting / mailing
* comment: layout translated based on template 'lang' field definition
or fallback on current user's lang;
* mailing: no layout supported;
PURPOSE
Translate layout into recipient's lang when available, instead of either
current user or template defined lang. As it is contextual better translate
it to the end user lang.
SPECIFICATIONS
Move recipients and email layout rendering into a method returning an iterator.
That way a list of recipient groups (as given by '_notify_get_recipients') can
be split into sub-groups, with each having its own rendering values for
email notifications.
Do a split / recipient lang. It is already fetched when notifying messages
as part of '_get_recipient_data' returned values. We now return recipients
groups per lang and per usage type (user, portal, customer, ...). Rendering
values are computed for each group as several values depend on the lang (
actions, notification buttons, global layout, ...).
Layouts when posting are dependent on recipient lang, and not on current user
anymore. Template lang that forced the content lang is now used only as a
fallback when recipient have no lang.
SUMMARY
When a user in Spanish, posts using a template specifying the lang of the
customer on a record whose customer is in French, with a follower being
in English
* content will be translated following template choice, aka french;
* layouting for the french customer will be in french, layouting for the
english customer is in english, while the core content is always the
same and in french;
When a user in Spanish, posts some custome content on a record whose customer
is in French, with a follower being in English
* content is whatever the user wrote;
* layouting for the french customer will be in french, layouting for the
english customer is in english, while the core content is always the
same and in french;
Task-3046371 (Mail: Better Language Support in Composer)
Task-2555155 (Mail: Translate notification action/access buttons)
Task-3186426 (Mail: Support notification layout in template / email composer)
Part-of: odoo/odoo#106177
Co-authored-by: Julien Banken <jbn@odoo.com>
RATIONALE
Naming conventions
* content = core message / subject (+ other fields);
* email layout = layouting applied to messages when sent to recipients who
receive notifications by email e.g. access button, ...;
* comment mode / mailing mode: composer main composition mode: posting on
record(s) / sending a mailing on records;
Content situation when using a template to post on a composer
* comment, monorecord mode: choose a template, content is rendered directly
from template side according to 'lang' field definition -> ok;
* comment, multirecord mode / mailing mode: choose a template, content is
the raw content. At post / send, content is rendered and translated if
matching template content -> ok;
Email layout situation when posting / mailing
* comment, monorecord model, using a template from UX: layout is partly
translated based on template 'lang' field to match the content translation.
Part of the layout still uses the current user lang;
* other comment use cases: layout is translated based on current user lang;
* mailing mode: layout not supported;
PURPOSE
Correctly propagate lang from template in all situations whenever a template
is used, and translate all layout parts.
SPECIFICATIONS
When using the composer to post messages (either as comment or in batch) the
language coming from the template is not propagated until the notification
process.
A hack has been done to try to guess the language inside the notification
process, based on context keys at odoo/odoo@9e71d228ed. This was done to partly fix
the bug in stable.
Since odoo/odoo@3eb9680602 it is possible to propagate a lang from 'message_post' or
'message_notify' calls until the notification process. We can therefore call
the posting methods using the rendered lang (in both mono and multi record
modes) and remove that hack.
When a lang is propagated using the 'force_email_lang' it is used to choose
the language of the layout (content, buttons). Currently all recipients
receives the same language for layouting. We plan to soon use the recipient
language when possible, then fallback on that forced lang. This will offer
more granularity and a better user experience.
When using scheduled messages (creating message but delaying the sending of
notifications) it is also working as notification parameters are saved when
creating the scheduling record, see odoo/odoo@9b11a9d82b.
EXAMPLE
A user in english uses a template on a lead whose customer is in spanish
with a follower being in german. Template lang is customer's lang:
* content is translated into spanish (customer's lang);
* layout is translated into spanish (customer's lang);
Both recipients (customer and follower) receive the content in spanish.
LINKS
Task-3046371 (Mail: Better Language Support in Composer)
Task-2555155 (Mail: Translate notification action/access buttons)
Part-of: odoo/odoo#106177
This commit contains mainly code cleaning, docstrings and a small split
for notification tool methods. In this commit we
* make some notification groups variable explicit;
* move the filler of groups into its own submethod to ease being called
from other code (to be used soon);
* fix some strange overrides or code manipulation;
* propagate some additional parameters to ease future commits that will
improve rendering of groups-based notification emails;
* cleanup, fixup and improve docstrings;
This does not change anything from functional point of view, just preparing
further work.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#106177
When being notified on a document they cannot read users should be able to
post, as indicated in message ACLs. However some data preparation prevents
from doing it as ACLs are raised on document level.
In this commit we sudo the call to display_name to populate record_name when
not given. Indeed access is checked at message level so no need to crash in
this specific use case.
Task-3213982 (Mail: fix 'multi-company' post support)
X-original-commit: odoo/odoo@2d73c61136
Part-of: odoo/odoo#114511
When replying on a document they cannot read (notably when being notified)
ACLs raise when trying to check if 'main_attachment_id' is already set before
updating it. This is fixed in this commit. This fixes the recently introduced
'test_post_wo_access' test that does not pass without this fix.
Note that the update of 'main_attachment_id' was already done in sudo. As all
read or update access is now done in sudo, better call the whole method as
sudo in 'message_post' and let '_message_set_main_attachment_id' works on
the given record set environment.
Task-3213982 (Mail: fix 'multi-company' post support)
X-original-commit: odoo/odoo@0375bb227a
Part-of: odoo/odoo#114511
The attribute _mail_post_access='read' on a model allows user with read only
access on the model to post a message. It was not taken into account on the
client side, making the send message button disabled for user with readonly
access on such model. This commit fixes this issue and now correctly takes
into account that class parameter.
Task-3178885 (Mail: fix 'readonly' post support)
X-original-commit: odoo/odoo@d2b8612cf7
Part-of: odoo/odoo#114511
The attribute _mail_post_access='read' on a model class allows to post on that
model with readonly access. But when providing an attachment such action was
throwing a security error due to the check done on the attachment. Indeed
adding an attachment to a model is modifying that model so the write access
is needed. To solve this problem, we add the attachment in sudo in the
'_message_post_process_attachments' method.
Justification
This is an internal method and we have stated in its documentation that it is
the caller responsibility to check the rights. Actually, the checks are done at
mail.message creation (to which the attachment are linked) by the override
of 'check_access_rule' which calls '_get_mail_message_access' which takes into
account that attribute (_mail_post_access). Moreover sudo is already used
in '_message_post_process_attachments' to link existing attachments. Here we
add a sudo for the new attachments as well.
Note
This fix allows the test 'test_post_with_read_access' to pass (located in
test_mail/tests/test_mail_multi_company.py). But it is currently hard to
reproduce functionally as
- answering an email works as it is executed by the cron;
- replying in discuss trigger a multi company error no matter there is an
attachment or not (so it is another problem);
- sending a message (with readonly access) on a thread from the interface
works without this fix because the attachment are created beforehand and
the part that handle already existing attachment is already in sudo;
Multicompany issues will be solved in the next commits.
Task-3178885 (Mail: fix 'readonly' post support)
X-original-commit: odoo/odoo@f9a6f7f7ce
Part-of: odoo/odoo#114511
Nasreddin Boulif (bon)