It is sometimes desirable to completely remove a field
from the automated tracking message
when setting a custom message that already covers the change being made.
Add a filtering method on threads to allow models to selectively
hide tracking values from emails and messages.
task-2974500
closesodoo/odoo#109606
Related: odoo/enterprise#31795
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Problem
---------
Previously, when receiving an email with several attachments, we created
1 invoice that contained all the attachments.
Objective
---------
We want to create several invoices depending on the attachments received.
No invoice should have more than one PDF document.
No invoice should have more than one XML document.
Other attachments should be placed in seperate invoices (except for the
first invoice that can contain 2 attachments: ex. image and PDF).
Solution
---------
Update the _extend_with_attachments to behave like such.
task-3526248
closesodoo/odoo#140196
Related: odoo/enterprise#49779
Signed-off-by: Laurent Smet (las) <las@odoo.com>
This commit introduces a new optional feature in the chatter.
Users can request translation from the Google Cloud Translation API.
Documentation: <https://cloud.google.com/translate/docs#docs>
Adding the key in settings will instantly enable the feature for all
users of the database and consumption is not measured nor limited
by Odoo as it is natively supported using the Google Cloud Console.
Translation values are stored in the database to reduce cost as
much as possible. Therefore, translation values are automatically
garbage collected every 2 weeks to prevent database pollution.
Task-3338165
closesodoo/odoo#126555
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS: MAIL.MAIL
Update MailMail to use alias domains. Notably "Return-Path" headers are
now computed based on alias domain when possible, using the recently added
fields on 'mail.message' model for that purpose. Fallback is to use current
company's bounce email when mail_mail creation is done outside of classic
mail flows or without that information.
SPECIFICATIONS: IR.MAIL.SERVER
Update IrMailServer and low-level stack to use alias domains. This has an
impact notably on default values computation for from and bounce emails
* '_get_default_bounce_address' is called when there is no 'Return-Path'
given. Most classic mail flows will set it according to current record
company / alias domain. Fallback when not set is to fallback on current
company's bounce email, computed based on its alias domain;
* '_get_default_from_address' is used in two use cases
* computing a default 'email_from' for outgoing emails when it is not set.
In most classic mail flows it is set based on current user's email. If
not set fallback on current company's notification emails is considered
as a safe bet, replacing the global configuration parameter;
* overriding the 'email_from' of emails that are considered spoofing the
mail server, allowing to wrap the sending into a 'notifications@domain'
generic sender. For those we should try to keep record's information as
it may be called in classic mail flows;
* '_get_default_from_filter' is added in base and overridden in mail to
either use 'mail.default.from_filter' ICP, or use the one defined on
the alias domain. Supporting both is still an option, as its behavior
is implemented for basic email sending, without mail being available.
Those methods are updated to try to support multi domains / multi company
setup. However as those defaults are located ar ir.mail_server level it is
not always easy to have complete environment information, hence fallbacking
on current company's parameters when no better information is provided.
A test about 'mail.default.from' is removed, as it was testing a default_from
outside of catchall domain. It is not possible anymore as default_from is now
part of domain definition. As multi domains is supported, no need to support
exotic configuration like that.
SPECIFICATIONS: FROM MAIL.MAIL TO OUTGOING EMAILS
When sending emails based on MailMail, we now prepares sending groups based
on MailServer, email_from, but also alias domain to which the mail belongs to.
Information about alias domain (e.g. notifications email based on default_from
and bounce email) is propagated to low-level email preparation methods. It
uses the context as it is the easiest way to propagate information to that
level without hacking too much models or calls.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Store 'company_id' and 'alias_domain_id' on 'mail.message' model. It helps
knowing the environment that produced the message, notably
* for layouting: it will be used to improve company (and soon alias domain)
given for the email notification layout;
* for sending: it will be used to better compute mail-related values like
default from, return path, ...
When logging, those fields are kept false as anyway no notification is sent.
No need to fetch extra information.
Some sudo() are included in post_* methods, as portal may go through the
posting method, see 'test_portal_acls' in test_message_post.py file.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Make mail gateway support alias domains instead of relying on configuration
parameters. This implies the following changes
* destination alias check is now based on full email by default. Previously
only left-part of aliases were checked. Optionally an allowed list of
domains could be additionally checked. Default from now on is to check
the complete email e.g. 'sales@mydomain.com' != 'sales@mydomain.in';
* detection of direct write to catchall implies checking all domains
catchall emails;
* detection of write to bounce implies checking all domains bounce emails;
* when having to send bounce emails using the bounce alias as mailer-daemon,
find the bounce email from the relevant company;
However we have to ease transition from the old ICP-based model used since
ages to the new domain-based model. Notably a common usage of mail gateways
is to do mail forwarding e.g. forward mail from domainA to domainB without
rewriting destination. It means that e.g. sales@mail.domainA should be
considered as a valid alias equivalent to sales@mail.domainB. This was
working due to left-part only check of destination aliases. In order to
keep this setup working after migration a flag is added on aliases allowing
to keep the detection of those aliases based only on local parts.
In summary: When searching for aliases, mailgateway now either checks for
exact email, either for matching local parts when the flag is active. This
is not the default behavior, as we want a stricter comparison of emails by
default but it will be the default behavior at **migration time**.
The 'mail.catchall.domain.allowed' configuration parameter is kept. It is
used only for left-part check aliases, allowing to limit the scope of the
match.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
When computing reply-to of message or documents, classify them per company
and use alias domains when computing catchall emails. Reply-to computation
based on alias is also simplified as aliases are now complete and use
alias domains. They do not depend on configuration parameters anymore.
LINKS
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
Perform some code cleanup not really related to other commits notably in mail
gateway where alias domains will have some impact. Extract some processing
in sub-methods, allowing to better distinguish code purpose. This implies
notably some checks in mail gateway (write to bounce or catchall detection).
In mail.message, reorder some fields according to their usage, just to keep
definitions / section.
Also improve docstrings and/or fix some of them.
This is mainly a "reduce diff in other commits" commit. No change should occur
with this commit.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
* = bus, crm_livechat, hr, mail_bot, test_discuss_full, test_mail,
website_livechat
Now that livechat uses guest, we can write proper ACL for channel and
channel member to check if the current user/guest is a member.
This allows removing most sudo in code and to simplify search domains.
Remaining sudo in discuss folder have been reviewed and commented.
task-3394829
closesodoo/odoo#138330
Related: odoo/upgrade#5295
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
We add the option to keep the completed activities to allow the user to keep
track of the past action, especially the uploaded files which are displayed
along the completed activities. This feature can be activated per activity
type and is disabled by default.
We also improve the activity view to give a better overview of what has been
done and what is still to be done and by whom.
We also add tests for those new features:
- check activity data for the views (server-side test)
* Details about the activity view improvements:
** Improvement of the column header:
- progressbar: previously, only visible activities were counted in the
progression bar. Now all are counted.
- activity counter: instead of displaying the total count (next to the
progression bar), we display now a ratio as 2 numbers (only if keep done is
enabled):
** Improvement of the activity cells:
- add assignees in activity cells of activity view (limit to 2 having the
activity with closest deadline, if more a + is displayed). Note: to avoid
spacing between avatar, we add the optional props noSpacing to the avatar
component.
- add done activity in activity cell popover
- increase by 50% the popover height
- display done activity cell in grey
- instead of displaying the activity count if greater than 1, we display a
ratio ongoing / activity count. Note: we don't display the denominator if all
activities are done or all are ongoing.
** Progress bar filter
The activity filter is slighly modified. Previously, when clicking on a color
of the progress bar, all cell with a different color where hidden (ex.: if we
were clicking on the green area to filter planned activities, red cell which
represents overdue activities were hidden even if there was also a planned
activities for this record and activity type). Now we also display cells with
other "color" if there exist for that record and that type an activity
corresponding to the filtered "color".
Technical note: mail_activity.get_activity_data returns now for the activity
types a list of dictionary instead of a list of list. This simplifies the
reading as we can now uses name instead of index (type[1] becomes type.name
for example).
Task-3300854
Part-of: odoo/odoo#138135
There is a o2m / m2o link between mail.message and mail.shortcode. However
this link is not used: 'messages' (m2o from shortcode to message) is never
set. Anyway there is no usage of this link: shortcodes are replaced in
message body and that's it.
Task-3557985 (Mail: Message cleanup (shortcode, link))
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#138938
- Remove "channel" field in thread formatter.
- Pass `type` for all persona formatters.
- Remove some snake_case to camelCase conversions.
- Add support for inverse fields in discuss JS models.
Details:
1. [REF] mail: remove field 'channel' in thread formatter
This field was used for channel-specific fields, which made
sense when there was a dedicated Channel model that was modeled
with composition with Thread.
To simplify formatter of threads, it's best to flatten props
so that channel-specific fields are immediately available on
thread model. This will improve insertion of data with Threads.
This commit also makes the following other changes:
- remove `discuss.channel/legacy_insert` to use
`mail.record/insert` instead.
- Introduce `toData()` on record, which is helpful to have record
in data format e.g. to pass as a JSON.stringifiable object.
2. [REF] mail: slightly simplify Message.insert from notif
The handling of `mail.record/insert` for Message was handling
transition from starred non-empty message to starred empty message.
To simplify all record insert from server formatted data, the notif
data is just inserted in Message. The adjustment of starred counter
is managed at model level.
This is a prerequisite to significantly simplify all
`mail.record/insert` handling.
3. [REF] mail: rename 'res.users.settings' notifications
Before this commit, notifications related to changes of user
settings were using named notification `mail.record/insert`.
This named notification should be only used for Discuss data that
should be inserted in models. `res.users.settings` is not integrated
in Discuss model, thus it has no reason to use this named
notification.
This commit rename the notification name to `res.users.settings` for
these specific notifications. This prepares simplification on
handling any `mail.record/insert` notifications that should simply
call `Record.insert()`
4. [REF] mail: make dedicate notif for Thread/fold_state
This was using named notif "mail.record/insert", which should
be used to immediately insert data in models. This is however
a dedicated notification to imperatively manager chat window
state based on timing of receiving thread data.
This may eventually become a `mail.record/insert` in the future,
but right now it's much simpler to define it as its own named
notification, in preparation to simplify `mail.record/insert`
notifications handling.
5. [REF] mail: remove Channel in mail.record/insert
This is replaced by `Thread`, so that these data can be
immediately inserted in Thread model.
6. [REF] mail: simplify slightly Attachment.update()
Now that data containing commands is supported, we could
just assign with the command rather than destructure and pick
the dict data part.
7. [REF] mail: introduce assignIn() utils
This function helps reduce LOCs from using the "in" conditional
in sequence:
```js
if (a in data) {
this[a] = data[a];
}
if (b in data) {
this[b] = data[b];
}
if (c in data) {
this[c] = data[c];
}
```
To simply:
```js
assignIn(this, data, [a, b, c]);
```
8. [REF] mail: remove snake_case to camelCase conversion in models
They exist for the sake of keeping Python code snake_case and
JS camelCase. While it's good that each language have a community
that prefer syntax convention, when a codebase uses both languages
and they should work with the same data, it's not great to convert
snake_case to camelCase and vice-versa all the time.
Since server has authority over the data, the server chooses the
format for the keys. Most of them are snake_cased, therefore this
is usually the one we pick.
9. [REF] mail: rename Message.messageReactionGroups to Message.reactions
Easier to read, and matches relation name in JS model
10. [REF] mail: remove explicit assign of some many relations in Message
This reduce amount of custom code in insert(), in preparation to make
all models behave the same in response to inserting data.
11. [REF] mail: rename Thread.customName to Thread.channel_custom_name
To match server data field name, and avoid useless conversion in JS.
12. [REF] mail: simplify Message.insert for recipients
Have formatted data contain `type: "partner"` so it can be assigned
in relational field without adding `type: "partner"` manually in JS.
13. [REF] mail: introduce inverse field in discuss models
With this commit, fields in different models can be linked
together, so that one is mirror of the other field.
This simplifies some `onAdd`/`onDelete` that were added to
sync such fields, and this also simplifies insertion in
relational fields for discuss models that are identified
by records, such as the `MessageReactions` that is identified
by the message and the emoji.
14. [REF] mail: rename CannedResponse.name to 'source'
To make JS model and server data more alike.
15. [REF] mail: remove assignDefined in Persona model
So that eventually all model inserts use `Object.assign()`.
16. [REF] mail: remove 'last_message_id' from channel_info
At some point it was used to display last message in messaging menu.
This is already covered by `channel_fetch_preview` when opening the
messaging menu for the 1st time, so passing `last_message_id` in
channel_info is obsolete.
closesodoo/odoo#137750
Related: odoo/enterprise#48484
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
'alias_user_id' field allows to set a user when creating records through the
mail gateway. This is however quite wrong and eases spoofing. The alias owner
is not the creator of any record, nor responsible.
Current possible ways of being owner / responsible of records created through
the mailgateway
* when you send an email to an alias: if you are recognized you are already
set as creating user and logged message author;
* it is possible to use alias_defaults notably to set fields like 'user_id'
if you want to be notified / responsible of records created through this
specific alias;
Those usages are therefore sufficient, no need to have another way to spoof
users. Moreover it is hidden in technical view of aliases, no model allows
to configure it by default. Moreover since odoo/odoo@3edf181 no default
value is given to alias_user_id as it adds more (ACLs / creator) issues than
really helping setting up mail gateway flows.
Task-3453482
Prepares Task-36879 (Mail: Multi-Domain Aliases)
closesodoo/odoo#138213
Related: odoo/upgrade#5259
Related: odoo/enterprise#48692
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current behaviour:
When creating a nameless contact,
while selecting delivery address type
for an existing company, there is a traceback
Steps to reproduce:
1. Install contacts,sale_management,crm
2. Settings > Sales > Quotations & Orders
3. Check "Customer Addresses"
4. Go to Contacts
5. Create a new contact
6. Check "individual"
7. Select a company
8. Select "Delivery" in Address type
9. Save => traceback
Cause of the issue:
Introduced by https://github.com/odoo/odoo/commit/9ef715fb994564af9e933ba31933a09eca97c24f
partner.name can be False
opw-3495748
closesodoo/odoo#138312
X-original-commit: baa731ac37818bcffcd7814b92456b37b8a97c61
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Antoine Demany (ande) <ande@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Before this PR, archived partner where displayed in the recipient list, but they
will never get notified.
This PR exclude archived partner from the recipient list.
task-3535433
closesodoo/odoo#137759
X-original-commit: a2474635c31d47e480f7a871aa869667f0a90dc5
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Didier Debondt (did) <did@odoo.com>
Since [1], live chat visitors are using the mail guest system for
authentication. With this change, visitors are allowed to reach the
attachment upload routes (even if nothing allows it in the frontend
for now). This commit restricts attachment upload for guest and portal
users with the `allow_visitor_upload` field that can be toggled.
At the same time, this commit enables file upload when authorized
on the frontend and for cross origin live chats.
[1]: odoo#129770
task-3332628
closesodoo/odoo#137574
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
PURPOSE
Simplify 'mail.tracking.value' model and code. Remove unnecessary fields and
computation. Make code easier to handle and more batch-enabled.
SPECIFICATIONS
Rename 'field' to 'field_id' on tracking model. It better indicates it is a
many2one and not a char field holding a field name for example.
Task-3345979 (Mail: Simplify tracking model)
Part-of: odoo/odoo#124182
PURPOSE
Simplify 'mail.tracking.value' model and code. Remove unnecessary fields and
computation. Make code easier to handle and more batch-enabled.
SPECIFICATIONS
Remove 'field_desc' and 'field_type' from 'mail.tracking.value' model. Those
can be retrieved when necessary, as it is mainly used for frontend display
in Chatter.
Task-3345979 (Mail: Simplify tracking model)
Part-of: odoo/odoo#124182
PURPOSE
Simplify 'mail.tracking.value' model and code. Remove unnecessary fields and
computation. Make code easier to handle and more batch-enabled.
SPECIFICATIONS
SPEC 1: prepare all tracking values at same code place
Delegate all computation of tracking values into the 'create_tracking_values'
method. Curently part of it (currency field) is done in the caller. Better
split code per feature.
Method is also made private, as it is not required to expose it.
SPEC 2: cleanup tracking value formatting methods and calls
Code used to display tracking value can be simplified: remove unnecessary
wrappers, make code easier to read, avoid composition of field name but
use a mapping instead (easier to grep 'old_value_char' when it is effectively
used).
Ensure code always calls '_tracking_value_format' to ease future improvements
and have all formatting code being batch-enabled.
SPEC 3: simplify Chatter formatted value structure
'fieldType' is currently added in old and new values. As it is a field
property it can be moved higher in the formatting result to be included
only once. Also add 'fieldName', the column name, to the formatted results
as it will soon help various tool methods. Moreover it makes sense to have
the source of the tracking as the real column name, in addition to its
string and type.
Task-3345979 (Mail: Simplify tracking model)
Part-of: odoo/odoo#124182
There is a double list encoding, probably not required. Coming from mail
enterprise code move.
closesodoo/odoo#137451
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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>
Renaud Thiry