How to reproduce
- Send an email to catchall@exemple.com, random@exemple.com
(Note : random@exemple.com is an email witch does not exist)
--> Issue the email is not bounced
To justify the change, this was actually the behavior a while ago, prior to odoo-dev@68a457e
The intent of that commit was to consider other possible routes, so this commit
doesn't contradict the change.
Task-3714565
closesodoo/odoo#161782
X-original-commit: df0c05afbf81ce41c9b1b4cfe93476d4ca397749
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Context
In a previous fix https://github.com/odoo/odoo/pull/83276
, the `_notify_get_reply_to_formatted_email` method was introduced
to prevent edge-cases where the cypthon `email` library might incorrectly
fold the “Reply-To” email header.
We identified an other corner case where DKIM signature verification
might fail on the recipient’s end depending on the tech stack used to
verify the DKIM signature vs the one used to DKIM sign it on the
sending end.
This might be related to how RFC5322 and RFC6376 interact with each other :
In RFC5322 defines folding white spaces as follows :
```
FWS = ([*WSP CRLF] 1*WSP) / obs-FWS
with obsolete FWS = 1*WSP *(CRLF 1*WSP)
```
While RFC6376 uses :
`FWS = [*WSP CRLF] 1*WSP
`
Based on this, it seems that for proper header content folding,
the specifications expects at least one WSP (space or tab) before a CRLF.
Currently when using the `email` cpython library to handle email
objects, we observed that when the header value for the “Reply-To” is
longer than 68 characters, it will return a folded string representation
adding a linebreak after the colon.
Example:
`Reply-To:\r\n "Marc R.Long Name Jonhson" <catchall@very.long.subdomain@example.com>\r\n`
Notice that the there is no WSP between the colon character an `\r\n`.
It seems that in this corner case, certain DKIM verification tech stacks
(from tests Microsoft Outlook and Rspamd) will miss-read the “Reply-to”
header as empty, while others correct for it (Gmail). This in returns leads
to the DKIM signature verification failing.
As it is impossible to test every possible combination of DKIM tech
stacks in the email ecosystem and that until the `email` cypython library
handles this corner case correctly, this fix tries to preformat the
“Reply-To” more defensively.
We also print a warning log if the `record_email` alone is longer than
68 characters (as it will not be folded), inviting the user to shorten
it to prevent DKIM verification issues.
Unit test fixing:
- shortened alias name to prevent the 68 character
limit from being triggered during the test_notification_reply_to_batch
performance test (as we are not testing the 68 char here)
- changed language in test_mail_message_values_fromto_long_name
to reflect the new 68 character limit and mutted
logger, as it now print a warning message
Considerations for the future
This PR only prevents the “Reply-To” from being malformed. In theory,
the miss-folding could happen to any email header constructed using the
`email` cpython library. In practice, the probability of the “To” and
“From” being affected is low, as they usually don’t exceed a total of
78 characters as per RFC.
Nevertheless if the future shows that this might be a bigger issue, one
should think about:
* On Odoo side: add a more robust header value formatting applied to all
affected headers before the email gets sent out
* On Python’s side: work with the `email` library maintainer to find a
longterm solution
opw-3826296
fixed test and conflicts in 17.0 FW
closesodoo/odoo#161014
X-original-commit: 894f981d04195861e757c052b7d10155cb5975b4
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When writing in a discuss channel, the updated value sent to the client
should be read from the database, not directly from the values passed to
the write method.
Partially backport of https://github.com/odoo/odoo/pull/139563closesodoo/odoo#158860
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Versions
--------
- 16.0+
Steps
-----
1. Have two companies with helpdesk teams;
2. create a contact associated with company 1;
3. create a contact associated with company 2 w/ the same email address;
4. from this address, send an email to team 2 to create a ticket.
Issue
-----
Ticket is created using company 1's contact.
Cause
-----
When searching for partners associated with an email address, it only
looks at the first one.
Solution
--------
Expanding on e1d50a404516d5b32bf01508423c5a1c880cb304 which prioritized
the current user, further prioritize based on companies matching the
records passed to `_mail_find_partner_from_email`, avoiding potential
access rights errors in multi-company environments.
Also fixes a bug in account_move where `_mail_find_partner_from_email`
was called with an `extra_domain` argument in the wrong position.
opw-3705199
closesodoo/odoo#159108
X-original-commit: 60dd5348179c9bdcc78e4ad46bd9b768a6e3ea21
Signed-off-by: Levi Siuzdak <sile@odoo.com>
* Adds text values for the call settings sliders.
* Replaces `onChange` events with `onInput` events so that the values
respect the position of the sliders.
* Debounces some functions to handle the increased amount of calls
due to the swap to the `onInput` listener.
* Changes the default value of `voiceActiveDuration` from `0` to `200`
to match the minimum value of the input.
closesodoo/odoo#151028
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce:
1. Install hr_holidays
2. Connect as Admin
3. Go to the profile
4. Check Handle in Odoo in Notification
5. In a private browser, connect as Demo
6. Go to Time Off
7. Take a day off
8. A push notification for Admin pops-up
9. The profile picture is wrong
Cause of the issue:
author_id is linked to res.partner not res.users
Fix:
Backport of: https://github.com/odoo/odoo/commit/1244c9c02d6242d34a37aa27168229e9d3939cb4
opw-3684987
closesodoo/odoo#155107
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
-Step to reproduce: any custom model that inherit from mail.thread then
define a field user_id but with type is char and boom error happen at
method '_message_get_suggested_recipients' because it always expect
'user_id' to be a many2one field
closesodoo/odoo#157942
-solution: need to check the type of 'user_id' also
X-original-commit: 4aaab353da1c1ddde63f2aa1232394c0b4dd6f68
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When adding alias domain in v17 support of configuration parameter
was dropped. We moved from singleton configuration to multi domains
using real models.
This means most of mail support lies in mail while part of it was in base
beforehand. In some cases we want to let people do some basic
configuration using base module then install mail which could migrate
this ICP based configuration into new models. This is notably the case
with odoo.sh where mail is not always automatically installed.
Use case is: install base, do some configuration using ICP allowing notably
to setup website / server domains, main mail configuration, ... then let
people install modules on top of that configuration which generally
installs mail. With this change existing ir.config_parameters matching
pre v17 names are now used to bootstrap alias domain table at mail module
initialization.
Task-3789584
closesodoo/odoo#156654
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Side effect due to a combination of odoo/odoo#124182 making field_id not
required to keep trackings when removing fields, and odoo/odoo@9c9552fd20
where field is used to find model when computing groups instead of message
in case the tracking is logged on a model different from the field model
e.g. accounting.
Steps to reproduce:
1. Install project_enterprise in saas-16.4
2. Create a task and update some values for Date deadline
3. Upgrade to 17.0
4. Try to open the task in the upgraded DB.
We get an error:
```
ValueError('All tracking value should belong to the same model.')
```
The reason is that `date_deadline` field is removed during the upgrade
and thus `fields_models` is empty in
https://github.com/odoo/odoo/blob/0649134444fa6b26de1c8c25d7c4a3f70c6d64e0/addons/mail/models/mail_tracking_value.py#L120-L121closesodoo/odoo#156571
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In odoo/odoo@9c9552fd20 a support of tracking value belonging to another model
than the message has been added. In such cases the formatting method written
at odoo/odoo#124182 fails as it expects a single model for all tracking values
it receives. When field is removed 'model' is False, and we fallback on
mail_message model.
Part-of: odoo/odoo#156571
When there is no channel members to be updated the seen status, we
should not send a notification to the channel members, otherwise it
will lead into creating a channel member with id undefined.
test case added to check that the notification is not sent when there
is no channel members to be updated.
closesodoo/odoo#156534
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Description:
Since https://github.com/odoo/odoo/pull/76734, the new field
`alias_full_name` is used in addition to `alias_name` to search on
`mail.alias` and route emails in `message_route`. It's also used as
a search criteria in `_search_alias_email` on `mail.alias.mixin.
optional`. The issue is that the table `mail.alias` can grow quite
large, and only the old field `alias_name` has an index on it, which
may not be selective enough, forcing Seq.Scans on the table with
possibly millions of records. The impact is noticeable on
`message_route` which is a hot path for processing incoming emails.
Adding an index on `alias_full_name` allows PostgreSQL to do an
bitmap OR scan on the two indexes, considerably speeding up search
criteria that are a disjunction between `alias_name` and
`alias_full_name`.
Benchmark:
For domain
```python
[
'&',
('alias_model_id', '!=', reply_model_id),
'|',
('alias_full_name', 'in', email_to_list),
'&', ('alias_name', 'in', email_to_localparts), ('alias_incoming_local', '=', True),
]
```
with test arguments, on a `mail.alias` table containing over 2M records.
| | Before | After |
|-----------|--------|-------|
| Timing | 696ms | 1ms |
| Buffer IO | 790MB | 48KB |
Specially impactful as those gains needs to be multiplied by the
frequency of the searches.
Reference:
task-3724844
closesodoo/odoo#156237
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
A new message type was added in stable. This is usually safe,
however in cases where there are related fields on that same selection
fetching them will raise an exception as the ORM has to fetch the translations
for the selection in DB.
We add a hack on mail.mail to update the selections in DB when fetching
the message_type field for the first time.
task-3773301
closesodoo/odoo#156235
X-original-commit: 19683173708a2b029acb4e744871772b6c248715
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Renaud Thiry (reth) <reth@odoo.com>
Steps to reproduce:
1. Activate dev mode
2. Go to Email Templates
3. Create a new template
4. Applies to Task
5. Email Configuration > To (Partners)
6. {{[p.id for p in object.message_partner_ids]}}
7. Click on Preview
8. Select a record with followers
9. Look at Recipients
10. => No or not all followers/partners are included
Cause of the issue:
Caused by https://github.com/odoo/odoo/commit/cf7ae6b9d562622709e2730c1ea8c43816c169bf
In the case of partner_to being '[2,3,4]'
Split would output '[2', '3', '4]'
So after the isdigit it would be '3'
It should have been 2, 3, 4
opw-3677069
closesodoo/odoo#156307
X-original-commit: d2e473f5b2b1b0fa1eae0f2a1e3698d663af07d8
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
`_message_auto_subscribe` relies on `_get_subscription_data` to know who
is subscribed to what. This method uses a raw SQL query but doesn't flush
the relevant records beforehand.
This is not an issue in most normal cases, but if followers are edited manually
for example in order to merge existing records. It may cause issues when
assigning a user to the record after merging, as the this will attempt to add
them to the list of followers automatically, when they already were on it.
task-3713472
original issue in opw-3634410
closesodoo/odoo#155139
X-original-commit: d1b0e46f7d3034c400ba3c60f343c21c68aa011e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Renaud Thiry (reth) <reth@odoo.com>
How to reproduce:
- Install CRM with demo data
- Configure one activity type to keep done activities
- Go to CRM and chose a kanban column with a green status (only planned
activities for that state)
- On a lead of that column, add an activity of the type chosen above with a
deadline in the past
- When going back to the kanban view, that column has the overdue status (red)
- Mark that activity as done
- Reload the kanban view
The kanban column has still the status overdue (red) while there are no more
overdue activity in that state.
With this fix, after reloading the kanban view, the header displays the correct
status summary. In the example above, the kanban column header is green.
While adding test, we have noticed that the 2 methods _read_group_groupby and
_search_activity_state were computing the activity state differently leading to
inconsistency. Actually, the newly added test was failing because the
read_group was returning 2 overdue records while only one was. We correct this
here as well by using the same computation in the 2 methods.
Technical note: archived activities were returned when grouping by
activity_state because that part was done in SQL and not taking into account
the recently added active field. While adding it in the "_read_group_groupby"
method, we also add it in "_search_activity_state" to avoid the same problem
when searching on activity_state.
Task-3732333
closesodoo/odoo#153274
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
- Create an invoice and confirm it
- reset to draft
- change the account of an aml (product sales -> asset)
-> on the log note you will see the detail of the modification `Account: 400000 Product Sales -> 101000 Current Assets`
- connect with Demo
- go on the same invoice
Issue:
You will not see the details of the aml account change
This is problematic since Accountant and auditors should be able to see it.
Cause:
Sub-model tracking is not supported. Although we override this constraint in accounting (refer to https://github.com/odoo/odoo/blob/f56de22f10d09e6e34b25cbff04bbb6bf0823e54/addons/account/models/account_move.py#L5058-L5071), it remains inaccessible for users other than base.system. This is because we attempt to locate the account_id field on the model account.move defined in tracking.mail_message_id.
opw-3632295
closesodoo/odoo#155034
X-original-commit: 20f00a73cb280fd9a3636122c4a8a316abcee0d0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
How to reproduce:
- Install hr with demo data
- Create a user without access to hr and turn it into an employee
- Create a user for Abigail
- Assign Abigail as manager of the new user
- Click on "onboarding plan" in the chatter of the new user
- Then in the dialog, click on "Schedule" button
You get the error "Assigned user test has no access to the document and is not
able to handle this activity." because the new user has no access to the record
employee on which those activities are scheduled.
As activities for which the user has no access to the underlying record are now
displayed in the systray (with no access to the record), we remove the check
that prevent assigning an activity to a user on a record he has no access to.
Technical note: before odoo/odoo#149965, activities scheduled manually were
created with the flag "automated" set to True and when this flag is set the
check that ensures that the user has access to the record is skipped. With
odoo/odoo#149965, as the "automated" flag is set to False when scheduling
activities manually, an error is trigerred if the user has no access to the
underlying record. Here we always skip that test and mark the method as
deprecated because the user can see the activity no matter the access he has on
the underlying record.
Task-3598836
closesodoo/odoo#155576
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Ease understanding the purpose of main fields on alias domains. Set bounce,
catchall and default_from available in debug mode as those are advanced
configuration bits that should be displayed (and modified) with care.
Add tooltips on fields to ease understanding the field usage.
Task-3696224
closesodoo/odoo#150401
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When a message is posted, the server sends a `mail.record/insert`
notification to update the related channel pin state. In order to
recognize the thread, the client needs its id and its model.
Currently, only the id is passed so the thread pin state is not
updated. This PR adds the model to the notification.
closesodoo/odoo#155150
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
__getitem__() of BaseModel, reset the prefetch set of the recordset.
Fix _compute_activity_date_deadline, to batched the reading of
activity's deadline.
closesodoo/odoo#154860
X-original-commit: ef7226aaa2f0ad135133fe27bdf1414b7ebf2a92
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Part 1: _search_is_member
-------------------------
Separate query to fetch candidate channels because the sub-select that
`_search` would generate leads psql query plan to take bad decisions.
When candidate ids are explicitly given it doesn't need to make
(incorrect) guess, at the cost of one extra but fast query.
It is expected to return hundreds of channels, a thousand at most, which
is acceptable.
A "join" would be ideal, but the ORM is currently not able to generate
it from the domain.
`sudo` is added as well because the rules for the member don't need to
be checked as no information is leaked.
Part 2: clean rules
-------------------
The rule for reading "self" is included in the rule for reading other
members. It can be disabled for "read" to avoid duplicate.
It also checked is_member again, but is_self necessarily implies it.
Part 3: clean tests
-------------------
The opportunity is taken to fix the tests. The tests where considering
as "access error" when there was an assert error inside the test (for
example not finding the channel or the member), but those needed to be
considered as failure regardless of expected outcome of access check.
Extra mute loggers are added to clean the test output.
closesodoo/odoo#153697
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
*: mail.
This PR removes the live chat sidebar category. From now on, each
channel will have its own category. This is a first step towards
providing an efficient way for operators to join/leave a live chat
channel.
part of task-3640730
closesodoo/odoo#154755
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Since 16.3, opening the web client on the Odoo backends results in two
subscribe events being sent through the bus websocket.
Discuss listens to the thread changes to know when the subscription
should be refreshed. In order to do so, the last subscription that was
made is kept. This issue is that this subscription is empty in the
first place so the first evaluation always considers the subscription
should be made.
In order to fix this issue, this PR refine the condition to determine
if the subscription should be renewed:
- The last subscription is different from the last one
- The user joined a channel after the bus initialization
- The user left a channel after the bus initialization
In order to test those scenario in a reliable way, this PR also
backports odoo#147455
closesodoo/odoo#154170
X-original-commit: 109b45f
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
1. Make sure to return archived users in partner format.
2. Remove the condition to check for archived users in suggestion code.
The condition made no sense since the refactoring (that's the opposite
of what we want, and it didn't compare the partner records correctly).
The feature is broken since https://github.com/odoo/odoo/pull/133065/
because it "fixed" the way records are compared. Making the condition we
don't want in the first place actually working and excluding OdooBot
(instead of allowing it).
3. Since archived partners are displayed anyway since the refactoring,
and nobody complained, let's consider it a wanted feature.
Archived partners are given lowest priority and moved to the bottom.
task-3747277
closesodoo/odoo#154078
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
A user that is not admin cannot create an mail.alias.
We can create the alias in sudo since we control the default_values and
model that are created with the new alias.
Check the _check_alias_domain_id_mc constraint in sudo because non amdin
user cannot read model ir.model.
closesodoo/odoo#153222
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Steps:
- Go to any event with tickets and using the ticket confirmation
template, sending 'after new confirmation'.
- Confirm a new attendee.
- An email is sent but the chatter only shows the attachment and the
subject, with no body.
Issue:
Chatter should show full content of the email.
Reason:
Above 16.2+ the 'body' is not implicitely set when genrating the
template in ``mail_template.send_mail()``. As discussed with RETH, when
requesting the 'body_html' for a template, setting the 'body' solves the
problem.
opw-3562438
closesodoo/odoo#151930
X-original-commit: 0a3d4b10a7c81d05d9bf6864b0b9a2f48f09b2a0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When a 'scheduled_date' is given to posting API notifications are delayed.
They are send using a cron running on a schedule model. However SMS are
not respecting this parameter. This is now fixed.
We also use sql.now() instead of datetime.now() when checking notification
delay. This leads to values that are consistent through the transaction
and avoid non deterministic behavior.
This leads to fixing a global mock of "cr.now" that has unexpected side
effects in composer tests. Indeed now that the scheduled notification checks
cursor now instead of datetime now this global mock leads to some notification
not being sent. We now mock cr.now() only for creating records, allowing
to effectively test templates using create_date for dynamic scheduled date
computation.
closesodoo/odoo#150911
Related: odoo/enterprise#55052
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Now that code is fixed there are more access to channel members and partners
to send them push notifications notably. Some tests are crashing when public
users access channel pages and perform actions that send push notifications.
Task-3695571
Related to Task-3669738 (Mail: Web Push Models Rename and Fixes)
Part-of: odoo/odoo#150011
Backport of odoo/odoo@1955c55f86
Sending notifications can be delayed by giving 'scheduled_date' as parameter
for notification process. This is used notably when a process in several
steps should wait for some user input before sending notifications e.g.
rating feedback and update done in two steps.
Sending web push notifications should respect this scheduling as already
done by inbox and email notifications.
Task-3695571
Related to Task-3669738 (Mail: Web Push Models Rename and Fixes)
Part-of: odoo/odoo#150011
Backport of odoo/odoo@24ebd74dc9
Recipients on a channel notification are computed twice: once using an
override of '_notify_get_recipients' that fetches information of mentioned
recipients; once in override of '_notify_by_web_push' to try to add
recipients for push notifications.
However this is not the right way to do it. Everything should be computed
in '_notify_get_recipients', setting the right 'notification_type' and then
let 'notify_by_MEAN' methods deal with their recipient input.
In this commit we now correctly compute recipients on a given channel
* mentioned partners;
* unmuted members on chat channels (push);
Task-3695571
Related to Task-3669738 (Mail: Web Push Models Rename and Fixes)
Part-of: odoo/odoo#150011
Backport of odoo/odoo@f312762c6a
'_notify_thread' calls '_notify_thread_by_web_push'. There is therefore no
need to call it once again in discuss.channel override of '_notify_thread'.
Task-3695571
Related to Task-3669738 (Mail: Web Push Models Rename and Fixes)
Part-of: odoo/odoo#150011
Backport of odoo/odoo@e3125c8389
A lot of keys are missing compared to standard '_notify_get_recipients'.
This is done in two methods that are updated to include keys defined
in 'MailFollower._get_recipient_data()' that contains the reference
structure to return.
Task-3695571
Related to Task-3669738 (Mail: Web Push Models Rename and Fixes)
X-original-commit: 7a46a957764aa5ee97a0a183fa1b747de85ff8ac
Part-of: odoo/odoo#150011
Just extract some code we should otherwise copy in both mail_mobile and
mail_enterprise.
Task-3695571
Related to Task-3669738 (Mail: Web Push Models Rename and Fixes)
X-original-commit: a6b0e88d00e1dcd4abbc1e37d62d65063c6956de
Part-of: odoo/odoo#150011
How to reproduce:
- Install contacts
- Go to any contact
- Schedule an activity on the contact by clicking on "Activities"
The flag automated of the created activity is set to True which shouldn't be
the case (you can check either in the DB or by adding the field with studio).
The same happens when scheduling plan, scheduling activities on multiple
records in the view list or a plan on multiple records.
This fixes the problem by modifying the activity schedule wizard so that it
always creates activities with automated flag set to False.
Note that that flags is used to distinguish activities created manually from
those created automatically. Some flows automatically cancel automated
activities (e.g. cancel 'validate my ticket') but those should probably not
cancel user defined activities (e.g. 'ask customer to pay'). That's why we must
ensure that activity created manually have that flag set to False.
Task-3691827
closesodoo/odoo#149965
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Default_from on alias domain is currently managed like bounce or catchall.
We consider it is always only a left-part of an email address that should
be completed with alias domain name.
However and notably at migration default_from could contain a complete
email address. In that case better be defensive and keep the domain part
of the value.
Task-3690919
closesodoo/odoo#149887
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
'_redirect_to_record' is used notably when accessing 'mail/view' controller
used notably with email notifications ('See Document' link). In order to
try to avoid multi company issues a call to '_get_mail_redirect_suggested_company'
is performed in order to find the record's preferred company.
However it is defined on 'mail.thread' which means the redirect crashes if
invoked using a non thread record. This is quite rare but may happen with
models using a mailgateway implementation similar to 'mail.thread' without
inheriting from the mixin (see 'mail.group' model added in Odoo 16).
This limitation is present since a long time but is now more present since
odoo/odoo@f4523fcd92 .
Task-3689459
closesodoo/odoo#150309
X-original-commit: 9a366dcdb789d0f160871ee4d29a463e2641ca26
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, opening chat window from messaging menu
might not work.
Step to reproduce:
- open Discuss app
- Go to home menu
- Reload the page
- Click on Messaging Menu
- Click on chat item to open chat
=> Chat window is not open
This happens because when in the home menu from Discuss app
in background page reload, the URL contains the Discuss app
menu_id, but the action is "menu" rather the action id. This
difference is crucial to distinct discuss app being actively
open or it's in the background from home menu. The latter
should NOT consider Discuss app being open.
This is not a problem when opening/closing Discuss app, because
the mounting/unmounting of the Discuss app component is good
enough to detect that. However, with page reload, the way to
detect Discuss app being open from URL was only relying on `menu_id`
instead of `action` value.
This commit fixes the issue by checking `active_id` of discuss app
rather than `menu_id`, as `active_id` is 100% reliable whereas
`menu_id` is not. The problem with home menu is one example among
many other cases (e.g. page reload in channel settings form view).
closesodoo/odoo#149969
Related: odoo/enterprise#54638
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
In large database, the time to unlink a sale.order (or any record with mail.thread) can be take 1 seconde.
After it is so fast.
closesodoo/odoo#149296
X-original-commit: 6bd9f408a18c019416b5bd981de50b54432f5690
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
do not compare types, for exact checks use `is` / `is not`,
for instance checks use `isinstance()`Flake8(E721)
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Fix various use case of HTML encoding / escaping in mail flows. Depending on
functional flow HTML entities could appear as they were not correctly
managed as valid HTML.
Notably when managing attachments in '_process_attachments_for_post' we
should return Markup-ized HTML to be sure it is considered as valid in
other post processing.
Task-3675159 (Mail: correctly escape HTML when updating content)
Task-3619348 (Mail: propagate markup flag when processing attachments)
closesodoo/odoo#148769
X-original-commit: f4bf63077d4129807e00e15b833e47623869491f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this PR, I guest searching in discuss would get an access error.
This is because the search is searching in the attachments that the guest can't
access.
task-3637314
closesodoo/odoo#146110
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Mismatch of str and Markup led to escaping everything. Now properly
Markup code and escape the rest.
closesodoo/odoo#146399
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
The kanban view used to display message history of livechats sessions is
replaced by Discuss for a smooth and consistent user experience.
Minimum viable version for Task-3497801
closesodoo/odoo#146800
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Threads are automatically marked as pinned when they are opened but this
behavior is not always desirable. They are now implicitly pinned when it
makes sense to do so.
closesodoo/odoo#146841
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
In [1], a context object was added to websocket requests to subscribe
to guests channels on cors live chats. However, the common mechanism
to subscribe to record channels is to pass a string channel that will
then be validated by the `_subscribe` method of `ir_websocket`. This
approach works with OdooSH out of the box while the other one does
not.
This PR removes the mechanism introduce in [1] in favor of the string
approach.
[1]: https://github.com/odoo/odoo/pull/130052closesodoo/odoo#147114
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Some printers incorrectly specify the content-type of PDFs as "pdf" instead of
the correct "application/pdf." To handle this situation,
an alias has been introduced, treating content-type "pdf" as "application/pdf."
[Reproducing original bug]
1. run odoo with documents module
2. prepare email file
2.1 create email with a pdf attached
2.2 export email to .eml
2.3 modify content-type of the pdf from "application/pdf" to "pdf"
3. send prepared email to odoo to inbox-financial alias (the default one
creating documents)
4. Go to documents, observe that the created PDF is blank!
[Motivation for fix]
Since:
1. Odoo uses the Python built-in module for parsing emails*
(the actual issue lies outside Odoo code).
2. "pdf" is not an accepted MIME type according to current norms
(https://datatracker.ietf.org/doc/html/rfc6838#section-4.2).
It's not an actual Odoo bug.
However, redirecting this issue to the appropriate printer manufacturer and
waiting for a fix may be time-consuming, hence the proposed fix.
*function parsing email with the Python built-in module
https://github.com/odoo/odoo/blob/407ea60796a2b18eb02f5569e1cfab9f1163a572/addons/mail/models/mail_thread.py#L1282
opw-3462260
closesodoo/odoo#147363
X-original-commit: e95a19341536e442239a7e940089d7f66ab9f534
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The SFU is a server used to relay streaming between the participants of
a call to provide better scalability and performance than the current
peer-to-peer connections.
The required fields have been added in https://github.com/odoo/odoo/pull/138581
* `/mail/static/lib/discuss_sfu` contains the client code that is used
by the odoo client to interact with the SFU.
From: https://github.com/odoo/sfu/releases/tag/v1.0.0
* The Json Web Token code has been extracted from `web_push` while
adding support for the HS256 algorithm, to be used as the authentication
method between the SFU and Odoo.
* The python code has been updated so that the odoo server requests a
channel from the SFU when going above a participant threshold, and swap
the participants to a SFU connection afterward.
* `rtc_service.js` has been updated to support both peer-to-peer and
SFU modes.
* The `call_context_menu` has been updated to display information
relative to the SFU connection when in SFU mode.
task-2765922
closesodoo/odoo#132153
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Summary
-------
Currently, duplicating a journal results in the new journal's mail alias
name overwriting the original's.
Steps to reproduce
------------------
* install `account_accountant`
* duplicate the "Vendor Bills" journal
=> you should see that the alias name of the new journal overwrites the
alias of the original journal.
Cause
-----
When duplicating a journal, the new journal inherits the alias of the
original. Because of this, a specific code segment intended to generate
missing aliases for new sale/purchase journals, inadvertently modifies
the name of the alias.
opw-3597349
closesodoo/odoo#143771
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Florent de Labarre