Before this commit:
In systray activity, for some languages, when there were few activities (exceeded a certain
length of text), it would break the line to display the labels.
After this commit:
Now, to maintain the design integrity, the text has been truncated to visually display
the labels like "aujourd'hu.." and maintain the design consistency.
Task-3869856
closesodoo/odoo#162001
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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>
Before this commit, when a DM chat had a custom name, the
search was not taking it into account.
Steps to reproduce:
- Log in as Mitchell Admin
- Open a DM chat with Marc Demo in Discuss app
- Rename conversation to "Test"
- Open more than 20 chat/channels (can create 20 channels)
- type "Test" in the quick search of discuss app sidebar
=> The DM chat with Marc Demo is not visible in filtered sidebar.
This happens because the quick search was relying on `thread.name`,
which actually only matches exactly the UI when this is the name
of a channel or when a group chat is explictly named.
The actual thread field used that matches textual name of thread
is `thread.displayName`, and this field is synced with custom DM
chat if any.
closesodoo/odoo#161540
Signed-off-by: Sébastien Theys (seb) <seb@odoo.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>
* Current Status
- when remove attachment or message, The system will perform deletion on
the interface before performing deletion in the DB. However, in some
situations, exceptions will occur during the deletion process. So it
will happen that the attachment or message has been deleted on the
interface but still exists under the database. From a function that
helps optimize user experience, it will cause a worse situation with
user experience
* Solution
- Make rpc calls before deleting messages or attachments on the
interface
closesodoo/odoo#161023
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this PR, the error displayed in the public page was quite
cryptic. It was hard for the user to understand that error and even
harder to report it if needed. This PR makes the error more user
friendly.
task-3850559
closesodoo/odoo#160947
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before commit:
Long user names in direct messaging search are not wrapped, leading to
UI display issues.
After commit:
Resolved the issue where long user names were not properly wrapped in direct
messaging search. Now, when a user name exceeds the allotted space, it is
truncated.
Task-3748791
closesodoo/odoo#160141
X-original-commit: eaf0e073ef8689629541de33e9bcf167f0e6b8e8
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>
Example of steps:
- Open any record with a chatter
- Log a note
- Edit it
- Try to save
Actually it is impossible to save it, because we can not
perform a CTRL+ENTER in mobile and there is no button
This commit adds a button to save editing, using `fa-paper-plane`
icon similarly to send button.
opw-3784145
closesodoo/odoo#159092
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, when a user of in chat posted a message and
deleted it, all other users kept the chat as unread.
Steps to reproduce:
- Connect as Admin and March Demo
- Send a message to Admin as Demo in DM chat
- Demo deletes this message
- Marc opens the chat
=> the unread counter is 1 and cannot be removed
This happens because when a message is deleted, there's still a
trace of it but the message is empty. However, empty messages could
not be candidate of setting the last message being seing by a member,
thus members were unable to mark the chat as read until someone else
posted a newer message (and did not delete it).
This commit fixes the issue by taking empty messages into account for
setting last message message of member, which allow to mark thread as
read even when newer messages have been deleted.
opw-3764410
closesodoo/odoo#158943
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>
The push-to-talk extension service sends a message to the extension
when starting to check if it is enabled. If the response is received
before the RTC service is started, the answer is ignored, and the
service acts as if the extension were not available. This PR fixes
this issue.
closesodoo/odoo#158252
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.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>
'false' is displayed in the popover next to the recipients in the absence of an email address as well as the title of the recipients
If the partner has no email, it should show something like "[name] (no email address)]"
test added
task-3787703
closesodoo/odoo#157850
X-original-commit: 40a2df25301daaf24c123e0b67bff408eb8cd897
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Zelong Lin (zel) <zel@odoo.com>
Steps to reproduce
==================
- Go to Accounting > Customer Invoices
- Open any record with no attachments
- Drag & drop a pdf attachment on the chatter
=> The PDF viewer is empty
Cause of the issue
==================
When uploading an attachment from the FileUploader, the parent view is
reloaded.
This is not the case when uploading an attachment from the dropzone.
opw-3748853
closesodoo/odoo#157232
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Before this commit:
Switching to RTL mode would inadvertently revert the domain picker,
causing a disruption in the email format. The expected format is Alias@domain,
but it was displaying as domain@alias.
After this commit:
Now, the domain picker remains intact in RTL mode, ensuring that
the email format is correctly displayed as alias@domain.
Task-3624012
closesodoo/odoo#157091
X-original-commit: 26f67d4b4c5dbddd6d543949c4c6071e53c53515
Related: odoo/enterprise#58364
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>
Since PR #152893, `mail_activity_schedule_from_chatter` test was failing on some
runbot builds. The problem is, the `timeout` to make sure the activity
type input is ready (has its data) to click again, is not enough for all builds.
Instead of using timeout (which is not same for different builds), we can add an
extra step to check if the activity id input has its data after clicking on
dropdown, to proceed to the next steps.
fixes runbot-57738
closesodoo/odoo#156030
Signed-off-by: Maryam Kia (maki) <maki@odoo.com>
Before this commit, there could be race conditions in which a channel
could be removed while the call was still loading, this commit prevents
this issue.
task-3660964
closesodoo/odoo#149034
Signed-off-by: Thanh Son Dodeur (tso) <tso@odoo.com>
Not a guaranteed fix (not reproducible 1500 attempts), but applying
standard fix for `step` failing to use the new step helper.
runbot-54560
closesodoo/odoo#155925
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@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:
- Go to activity view.
- Schedule an activity for one record. (Say 8 records are available)
- Schedule an activity for the second time. (Again 8 records are available)
- Try to schedule an activity for the 3rd time. (Only 2 records are available)
Issue:
Since 7682286, the existing props of activity model are being passed as params
while scheduling an activity. Currently, `["activity_ids", "!=", false]` is
being pushed to the domain of activity model in order to display only those
records on which activities have been set. As a result, after you schedule
activities more than once, `["activity_ids", "!=", false]` domain gets applied
and the list of records available for scheduling activity is restricted from
the third time onwards.
Fix:
This commit passes the props from searchModel as params to the 'load' method
while scheduling activity, instead of existing props, to ensure that the
existing params are applied as well as all records are accessible for
scheduling an activity, in `searchCreateDialog`
(i.e.["activity_ids", "!=", false] condition is not added as domain).
Task : 3721750
closesodoo/odoo#155700
X-original-commit: 339df084567206cff8a5487bbe9dec249671244a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Khushi Patel (khpa) <khpa@odoo.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>
Before this PR, the `bus subscription is refreshed when channel is
left` test was sometimes failing. This actually reveals a real issue:
if a channel is joined a leave very quickly, the bus subscription is
not updated.
This occurs because we rely on the last subscription made and the one
that should be made to detect if channels differ. Since the
`updateBusSubscription` method is debounced, we can miss information.
This PR replaces the complicated `updateBusSubscription` method by a
`onAdd/onDelete`. This is much more reliable and more efficient since
there is no need to walk through every channel to detect changes.
This PR also remove a test that was redundant that the failing one.
fixes runbot-55292,57645,56232
closesodoo/odoo#155720
Signed-off-by: Sébastien Theys (seb) <seb@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>
1. channel mention should work for channels, chats, and groups, even if
there is a group restriction for the channel.
2. channel mention in livechat is disabled because the visitor can't get
access to the channel.
3. remove the fetch and search for channel mentions in livechat so that
there is no extra rpc call for unuseful data.
4. add a test for the channel mention in thread.
closesodoo/odoo#155380
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit:
Squashed transient messages had date displayed in the sidebar of the message.
This was introduced by this commit: 631ae1c
After this commit:
Squashed transient messages would not have date in the message sidebar.
closesodoo/odoo#154594
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.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>
Thibault Delavallée