The combined domain for moderated messages used to trigger a complex
database query with two OR conditions on the mail_message table.
Unfortunately PostgreSQL seems to be unable to optimize this with
indexes, or to detect that one of the conditions is void (included `AND
FALSE`). On large mail_message tables, this significantly slows down
calls to message_fetch, e.g. 6s instead of ~70ms, while returning the
same results.
As a workaround, move the logic for generating the moderation domain to
the server side, where it can be:
- optimized out when the user is not a moderator
- split into 2 distinct DB queries in order to avoid the pathological
case
After this change, calls to message_fetch with and without messages
to moderate execute in respectively ~50ms and ~150ms, instead of 6s, in
a test database with 25 million messages.
The modified message_fetch signature is backwards-compatible.
+ modified mock server used for the tests, which unfortunately
duplicates most of the business logic.
Other operators can only cause nonsensical results, while causing
useless slow queries. This is only really meant as a shortcut for
getting messages to moderate.
Since saas-11.4 the subtype dropdown don't keep changes of subtype.
Before saas-11.4 the update was relying on the fact that the follower id
changes on each subtype edition. This is no longer the case.
The test is addapted to remove the hack simulating this behaviour.
The read_followers route is not called if no there is no changes
in the follower ids
https://github.com/odoo/odoo/blob/905e01921f3c3ef43ace6fc537d1d8c0d280002c/addons/mail/static/src/js/followers.js#L195
Leading to the follower list not being update
Note that the subtype update in dropdown was working fine after adding a
new follower: the read_followers will return a None as suptype when called
for a list of partner not containing the current user. Since the subtypes
was falsy, the render was not rendering the dropdown again, keeping
the value of the checkboxes. We can still create some inconsistency by
editing the subtype from the follower list. To avoid that a check is made
when updating subtypes after calling read_followers.
The chosen solution here is to keep the update on subtypes in memory.
This will avoid a call on read_followers to fetch information that we
already know, using the assumption that the operation was successfull
whish should be the case when a user edit subtypes on a record
he has access to.
Others solutions:
-force the call to read_followers with the current user, maybe by removing
it from this.follower after editing subtypes.
-call read_subscription_data explicitely
Obviously follower.js should be refactored to fix this a better way.
Task: #1886982
PR: #27093
The 'help' of window action is often fiddled with, adding thing before,
after or arround it.
For example in CRM leads, we add at the beginning "Click to add a new
opportunity" with an arrow towards the button, and after if there is a
mail alias: "All email incoming to * will automatically create new...".
But for crm.lead, hr.expense, sale.order this would not take into
account that the fiddled "help" can be edited, so if we edit 2 times
help in studio or backend action editing, we would get:
Click to add a new opportunity
Click to add a new opportunity
Click to add a new opportunity
[Original help content]
All email incoming to * will automatically create new...
All email incoming to * will automatically create new...
All email incoming to * will automatically create new...
And see several "arrows" towards the button (in enterprise the
additional ones are on same color background).
With this commit we do what is done in "mail.thread" by default which is
not fiddling with the `help` if has been fiddled before (if it contains
"oe_view_nocontent_create" class).
note: this is the 11.0 version of #26912
opw-1877663
closes#26911
Have a send email automated action on invoices upon validation (write)
Go onto the credit notes, create one, and validate
Before this commit, at the creation of the attachment (the invoice pdf), there was a traceback
because default_type was in the context containing 'out_refund'
And that attachments also have a field 'type'
So the default_get of the latter got a value that wasn't correct for its field
After this commit, we clean the context of the default_type context key since it
is irrelevant beyond that point
OPW 1868638
closes#26621
On an activity, click Mark as done, the popover pops over
Now write some text in it, but click somewhere else, like to copy/paste something
The popover looses focus, and your text disappears
After this commit, we store the value of the popover when hiding it,
then, when when showing back the popover, the value is reinjected
OPW 1873999
closes#26315
We need to know if a notification is in failure by
displaying the red envelope in even if all partner are inactive.
This commit also fix the filter in order to display notification
of all active partners if there is an exception.
The user right to edit partners was handled in order to set email fields as readonly
If a user is in the failed recipient, we need to check that the urrent user also has
right to write on users
- When a tracked field is modified, a mail.message is created.
When create is called its tries to fill missing values with "default
values".
It first tries to find the default values in the context, which may
occurs.
For example, modifying a tracked field on a subtask will add a key
"default_parent_id" in the context, which is the parent_id of the project.task.
Create will try to use "default_parent_id" for the mail.message
parent_id field, which make the SQL Request invalid.
The search on message_has_error (used when clicking on a failure notification)
was displaying the failure of all users making it difficult to find your
own mail failure. This fix solve the problem by adding a criteria on message
author_id.
The default value for failure_type was the 'NONE', instead of being
simply False/NULL. This represents a significant waste of tablespace
with no added value.
Switching to true NULL value for representing the absence of error
also save some precious time during database upgrades on databases with
large numbers of emails.
While fixing the values for failure_type, also fixed a few typos and
untranslated strings.
See original feature at 133eeb1bbf
Steps to reproduce the bug:
- Let's consider the today date = D
- Set on your preference a timezone which has another today date = D+1
- Go to CRM > Configuration > Activiy types > Call
- Set 0 as # Days
- Go to CRM > Pipeline > Click on a lead
- Schedule an activity of type = Call
Bug:
The Due Date = D instead of D+1
opw:1877217
- When trying to fetch notifications for failed mail delivery, the code
doesn't check if the partner is active or not.
If the partner is archived, then it tries to access its information on
a dict that doesn't contains them and crashes.
On a SO, write a note to a user
The mail the user receives contains a follow button
Click on it
Before this commit, the link did not add the user as follower of the SO
this was because the wrong uid was passed to the function
After this commit, user is added as follower
OPW 1869849
closes#26634
Following 50ab18176 an access token is added in the URL, but there may
not be an existing access token. If so this commit generate one.
opw-1877347
closes#26526
- In some cases (merge of partners, etc ...) there might be mail.channel
that have two mail.channel.partner with the same res.partner.
When you try to open a discuss window with a partner for which you
have no existing mail.channel.
The channel opened is the one where your partner is duplicated.
This is due to the fact that the SQL request to find the mail.channel
doesn't take in account that a mail.channel may have twice the same
partner.
To fix this issue, we try to exactly match the partners we search.
This commit fixes two issues:
- If a partner has multiple users and if any of these users is a
share user, then the access button on mail notifications is not displayed.
- If a project.task is either assigned or has its stage folded
the access button may not be displayed for certain users.
The users affected by this bug are the one who have their user's
partner is linked to multiple users with at least one flagged as a share user.
Regenerate all child translations based on the .pot
Remove the terms that are either equal to the parent, either equal to the
source term.
Remove empty translation files
Olivier Dony