Base: seems related fields take only 1 extra query instead of 3
Crm: assignment seems to have been slightly improved. Some randomness still
happens.
Hr Holidays: seems it was further improved beyond space frontier
Hr Work Entry Holidays: seems it was further improved
Test mail: those tests were a bit random, seems random is gone (hopefully)
Test mail full: updated local counters
Test mass mailing: seems we gained one query, updated local counters
closesodoo/odoo#70504
X-original-commit: 8c215b3d60929166b3e60e2a4dfb2a6c70439046
Related: odoo/enterprise#18194
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
ALIAS_WRITEABLE_FIELDS is used to write alias fields with sudo
Steps to reproduce:
1. Create a user
1.1. Give rights Services -> Project-> Administartor
1.2. Not given rights Administration-> administartor
2. Project app -> open any project -> Action -> duplicate -> it give validation error.
---
opw-2506566
closesodoo/odoo#70414
X-original-commit: 7ae1b4622c6743e28deca12476d6e70375c9417e
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Create a company whoose name ends with a dot like "Bidule Inc.", change
the company of the user to that new company, head to the Accouning
module and create a new journal of type purchase. Traceback because the
generated mail alias for that journal uses the company name and that the
local-part of an email cannot ends with a dot.
From the RFC standpoint, the local-part of an email address (the part
before the @, `john` in `"John Doe" <john@example.com>`, cannot begins
with, ends with or contain following dots.
The email sanitizing function have been updated so it takes care of the
above requirement.
See also #61811
opw-2448692
closesodoo/odoo#69864
X-original-commit: f0e840ae6db387e1dfc99cc21e09d84eb126e7b9
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
PURPOSE
Rename fields on mail_thread and wizard: ``no_auto_thread`` should be replaced
to ``reply_to_force_new`` to ease understanding and be prefixed by reply_to.
SPECIFICATIONS
For better understanding, this commit renames ``no_auto_thread`` field of
``mail.message`` model to ``reply_to_force_new``, to indicate that if the
field is checked (☑) replies should check gateway alias rules instead of
updating mailed threads.
It is also more coherent with reply_to namespacing used in various mail models
(notably new composer fields and ``reply_to_mode`` of mass mailing and mail
composer models)
LINKS
Task ID-2117639
COM PR odoo/odoo#40931
ENT PR odoo/enterprise#17941
UPG PR odoo/upgrade#2419
PURPOSE
Right now, `reply_to` field on email template is misleading due to poor
explanation. This commit improves the placeholder and tooltip of the fields
to make the purpose of the field clearer especially for non technical users.
SPECIFICATIONS
Update reply-to field placeholder to "Preferred email address when sending
via mass mailing options".
Update reply-to field helper message to "Preferred email address when sending
via mass mailing options. <br> Only used when the answer is not added into
the original discussion.""
Update the no_auto_thread field label to "Reply to" in composer and introduce
a new radio button replacing the checkbox
* The original discussion (thread)
* Another email address (new)
Rename fields on mail_thread and wizard: ``no_auto_thread`` should be replaced
to ``reply_to_force_new`` to ease understanding and be prefixed by reply_to.
LINKS
Task ID-2117639
COM PR odoo/odoo#40931
ENT PR odoo/enterprise#17941
UPG PR odoo/upgrade#2419
Before this commit
When someone tries to send a mail to a restricted alias (which can be
anywhere in 'To', 'CC' or 'BCC') and if the sender is not allowed to do
so, the mail bounces. However bounced mail shows info as if it bounced due
to address provided in 'To', even though it is not always the case.
Example you send a message to
* 'To': 'valid@gmail.com' (okay)
* 'Cc': 'myalias@odoo.com' (not allowed for you)
Mail bounces because you are not allowed to send a mail to alias provided
in 'Cc', but it shows the message that: `The following email sent to
valid@gmail.com cannot be accepted because [...]`.
After this commit
Boucing alias is shown in message body. Above example becomes `The following
email sent to myalias@odoo.com cannot be accepted [...].`
Note: Because the alias can be present in `Bcc` too (which will not available
in the message values we get in `message_route_verify` method), we simply use
display name of the alias instead of finding mail address matching with alias
from the message values.
Task ID-2390310
closesodoo/odoo#69788
X-original-commit: 15325b19c15a649041db75bacbe8409ae4c58df7
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit:
When someone sends mail with help of mail_composer(mail.compose.message)
without having a mail template set, mail is not deleted after being sent
(and causes unwanted/unexpected burden on DB). This bug was introduced
with commit[1], where auto deletion was disabled if template is not set
on the composer.
After this commit:
If there is no mail template set on the composer, or if the template is
set and 'auto_delete' is enabled on that template, the mail sent from
composer will be deleted after being sent successfully.
A context key is added to allow controlling this behavior. It is notably use
to check query counters differences.
commit[1] - https://github.com/odoo/odoo/commit/8a026e26c6ae25e3fdb5369a7fa3343d70fab782#diff-898a3d5c08a567c1a7b82c026a213d796e850e376cbdb1c9e7936409f440d37aR257
Task id: 2484915
PR odoo/odoo#68870
Original Pr #68403closesodoo/odoo#69203
X-original-commit: d54973ee1b4457e3d1c0c8d9bf226928530d8b30
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In this commit we backport some of 14.1+ improvements done in mail tools
in order to keep a coherent definition through sub versions. We also
improve docstring and add some explanations on available toold and asserts.
Task ID-2500615
COM PR odoo/odoo#68874
X-original-commit: d44c47697389866603f28ff2d5da60a97574ec5f
This commits is a bit a followup of odoo/odoo#62061 where new composer tests
were added. This commit finalize this work by merging all composer related
tests within the same file. It also backports some of tooling update done
in odoo/odoo#64459 or odoo/odoo#63677 in order to have coherent naming
through 14+ versions.
Some additional or deeper tests are added. Notably it now more cleanly
uses asserts for created mail.mail and sent emails.
Task ID-2500615
COM PR odoo/odoo#68874
X-Original-Commit odoo/odoo@67f31cbfcd
X-original-commit: e147ca2eb51a7008251f20f134bd021a1ae3705c
- Connect with Admin
- Go to Contacts, edit himself by adding a Private Address
- Create an Internal User without "Access to Private Addresses" right (i.e. User X)
- Go to any app implementing chatter (i.e. Sales)
- Create a SO
- Add the created Private Address as follower
- Make sure User X can access the record (i.e. Sales: Administrator)
- Connect with User X and open the SO
An Access Error is raised while trying to fetch data about the followers.
This commit prevents to:
- add a private address as follower of a record
- add a private address as Recipient in full composer
- propose private addresses when adding a mention to a partner
opw-2428936
closesodoo/odoo#68493
Task-id: 2463622
X-original-commit: 20536e1bbeb641539c0de44364f8376e7cef651b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Current behavior before PR:
mail notification not sent when using the full composer.
Desired behavior after PR is merged:
mail notification will send when using the full composer.
LINKS:
PR https://github.com/odoo/odoo/pull/66421
Task-2446855
closesodoo/odoo#67933
X-original-commit: 349f07670ea4938e7fc3d9fa3a6fc5fae40dac65
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When Odoo routes incoming emails it is looking for existing messages in
database using Message Ids which are coming from e-mail header
References.
In Odoo the message id looks pretty long like
743570479975566.1584086032.522504091262817-openerp-message-notify@ip-172-31-45-160
As it declared in [RFC2822] long header bodies can be "folded" using
CRLF+WSP. And some mail clients do that very thing. They split
References header body which contains Message Ids by "\n ". The example
of mail client where it can be reproduced is apps.rackspace.com We
created Sales Order in Odoo, sent this quotation to the client email. He
replied with e-mail, and this email can't be matched with any existing
message id and as result it's not attached to the Sales Order.
RFC2882: https://tools.ietf.org/html/rfc2822#section-2.2.3closesodoo/odoo#68077
X-original-commit: 559f6cf62711ad45557eddec3af7c66616724eb5
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
After all those changes, query counters can be updated according to latest
runbot state. Some counters decreased, meaning simplifying models leads
to a performance increase. Hopefully. Or bugs. Or both.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
PURPOSE
Remove channel ability to follow records as it mainly adds noise without a lot
of added value. Simplify channel notification flow by using directly members
and not a delegation through a channel self-following trick. Remove followers
being channels and posting with added listeners being channels.
SPECIFICATIONS
In this commit we force messages to belong to a single document using
``model`` / ``res_id`` pair. It is not possible anymore to link a message
to channels using ``channel_ids``. A message belongs to a document and
is displayed in that document's chatter.
This change implies modifying a lot of domains, notably in chatter. Indeed
discuss for channels does not use ``('channel_ids', 'in', [3])`` domains.
They now use ``('model', '=', 'mail.channel'), ('res_id', 'in', [3])`` like
other documents fetching their messages.
This commit also removes ``channel_message_ids`` field on ``mail.channel``
model. As channels are now considered as standard documents they will use
``message_ids`` field like all other documents. Linking a channel on a message
is possible only as a link in message from now on. It is not possible to push
it into a channel anymore (no more listener channels, no more channel link).
Finally a global cleaning also linked to all previous commits is done.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
PURPOSE
Remove channel ability to follow records as it mainly adds noise without a lot
of added value. Simplify channel notification flow by using directly members
and not a delegation through a channel self-following trick. Remove followers
being channels and posting with added listeners being channels.
SPECIFICATIONS
In this commit we remove support of ``channel_ids`` parameter when posting
a message. This means we do not support notifying channels as side-part
of notification mechanism on a document. Either we post on a channel and
its members are notified, either we post on a business documents and its
followers are notified. There is no possibility to add channels as being
notified when posting a message.
This is done as a followup of removing followers being channel-based and
prepares ground to make channel use model / res_id as all other documents
inheriting form mail.thread.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
PURPOSE
Remove channel ability to follow records as it mainly adds noise without a lot
of added value. Simplify channel notification flow by using directly members
and not a delegation through a channel self-following trick. Remove followers
being channels and posting with added listeners being channels.
SPECIFICATIONS
As there is no way to add channel-based follower anymore we can remove all
fields and code supporting this feature. Notably we can remove ``channel_id``
field on ``mail.follower`` model as well all code using it, notably compute
methods.
In this commit we also make ``partner_id`` field required as now followers
are always partners. Email, name and active fields are now simple related
fields on the partner.
Code computing data about subscription is also updated and simplified. As
we do not have channels anymore but only partners all custom SQL queries
are now simplified.
JS models for Discuss are also cleaned. Following python change, JS models
are simplified to match the backend models. Channel_id is removed, partner_id
is now required, and various code is updated according to the simplified
model.
Side note: we could probably get rid of specific index on ``partner_id``
field. However we have to ensure we never search for followers without being
in a model / res_id context. This will be done in another cleaning step to
be sure performance are not broken.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
SPECIFICATIONS
Remove ``message_channel_ids`` field from ``mail.thread``. As we removed
support of (un)subscribing channel-based followers there is no need anymore
to have a field to access them. We can now safely remove this field as it
has no use anymore.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
SPECIFICATIONS
Remove ``channel_ids`` argument and support from ``message_subscribe`` and
``message_unsubscribe`` API. Indeed we do not support adding channel-based
followers anymore. Only partners should be added or removed from followers.
It also allows to simplify API and understanding of both methods.
Various addons are updated to match the simplified (un)subscribe API. Some
enterprise addons may also be impacted.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models..
PURPOSE
Remove channel ability to follow records as it mainly adds noise without a lot
of added value. Simplify channel notification flow by using directly members
and not a delegation through a channel self-following trick. Remove followers
being channels and posting with added listeners being channels.
SPECIFICATIONS
In this commit we remove the auto-follow mechanism on mail.channel. It is
used as a trick to have self-notifying channels. When posting on a channel
it listens itself. When a channel listens to a record its members are notified
depending on channel type. It means that a channel following itself notifies
its members in a magic way.
We decided to remove this magic and instead do a cleaner implementation of
this mechanism. ``_notify_compute_recipients`` method from ``mail.thread`` is
now overridden on channel model. It computes recipients to notify using a
custom SQL instead of the generic one given by ``mail.thread``. Some other
code adaptation is done to ensure notification on channel model is done as
intended on that specific model.
As channel model is somewhat different from classic mail.thread enabled
models let us implement its features in a more traditional way. More overrides
and less magic !
QUERY COUNTERS
Due to changes in ``channel_partner_ids`` fields being a computed inverse
searchable field there may be an additional query when performing a message
post as indicated by ``test_complete_message_post`` test. This is due notably
to message_format fetching channel_ids information. A call to ir rules on
channel is performed that uses ``channel_partner_ids`` as part its rule domain.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
Purpose is to use available tools, easier for debug and asserts than doing
everything manually. It prepares future changes in channel model that may
have an impact on bus notifications.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
A context key is added allowing to bypass user / channel synchronization
when creating users. This is used notably in tests to avoid subscribing
new test users to "general" channel created as default data.
Purpose is to avoid interferences in query-based performance tests. It also
avoids unnecessary data creation and/or update when it is not necessary
especially in tests.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
When formatting a message, a message could be with an empty or obsolete
record_name field. It's better to rely on the relation between the message and
the thread and fetch the current thread name.
task-2411715
closesodoo/odoo#63000closesodoo/odoo#67549
X-original-commit: 51e962803d2048efeb0f7e96a9fe561ac49ee05a
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This will count the number of query when formating messages, in particular for
the thread name query that is changed in the following commit.
Part of task-2411715
X-original-commit: 45b51acc35188765270a0b8b1dcaf5508408edf6
RATIONALE
A bit of history. Link between a message and its recipients has been added
at first mail refactoring towards a Chatter / Discuss feature. It was done
in v7 at d64f3c9783 with the base addition of mail notification model (lots
of commits follow that one but that's the first one about notification).
Due to some people thinking that it was unnecessary to keep a model for
notification it has been removed in v9 at 88b8cd0587. Notification table was
renamed from mail_notification to mail_message_res_partner_needaction_rel.
It was proven to be a mistake even if those "some people" were warned and
model made its way back to Odoo in v10 at 72dfcae2a4 . Table name mail_message
_res_partner_needaction_rel was kept to ease migration and backward
compatibility.
It is now time to complete the circle and rename it to mail_notification.
SPECIFICATIONS
Rename ``mail_message_res_partner_needaction_rel`` to ``mail_notification`` .
RIP JEM.
Never forget.
LINKS
Task ID-2477444
Prepares Task ID-2377974 (trace management cleaning task)
Prepares Task ID-2070632 (channel members main task)
Prepares Task ID-2419762 (channel members followup task)
COM PR odoo/odoo#67382
UPG PR odoo/upgrade#2245
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
The goal of this change is to simplify the code managing `create_date`
and `write_date` in methods `create()` and `write()`, and also to remove
weird behaviors caused by the way those fields were updated.
Assume we update a simple field on a record. This adds pending updates
for the field and `write_date`. However, the value of `write_date` is
not known yet: it will be updated as `NOW() AT TIME ZONE 'UTC'` in SQL.
So `write_date` is actually given a dummy value in pending updates, and
it is invalidated from cache, until its value is flushed to the database
and fetched again.
Now assume we access another field on the record, and that field is not
in cache. The prefetching mechanism will read all column fields,
including `write_date`, and flush them first.
# this adds pending updates foo: 42, write_uid: 1, write_date: False
record.foo = 42
# assume 'bar' is not in cache; this prefetches all column fields,
# which flushes the pending updates above before reading them back
result = record.bar
We can avoid flushing pending updates if the values read from database
do not overwrite existing values in cache. If you assume that the value
of a pending update is in cache (in the example, `foo: 42`), you don't
need to flush the corresponding field. Indeed, the value of `foo` will
remain 42 in cache, whatever its value in the database. This assumption
(pending updates are in cache) is true for all fields *except* for
`write_date`: it is invalidated from cache, and given a dummy value in
pending updates. This branch actually makes this assumption true for
all fields. The avoidance of flushing pending updates will be done in
another commit.
In order to directly assign `write_date` its value, we use a cache for
the value `NOW() AT TIME ZONE 'UTC'` from the database. This costs at
most one query per transaction, and potentially saves a few queries.
Co-authored-by: Victor Feyens <vfe@odoo.com>
Adapt some query counts to their optimal value, in order to measure the
effect of the following commits on queries.
In module test_performance, some query counts were actually not correct:
the initial flush() done by the context manager assertQueryCount() may
prefetch some data to the cache, and that prefetching is not accounted
for in the query count. This is very true when assertQueryCount() is
preceded by a cache invalidation. We have to move the invalidation
inside the context manager, so that the prefetching is now counted.
- Send the new Inbox counter when marking as read, to guarantee the JS has the
correct value (instead of having to guess it which was impossible when an
arbitrary domain was given to the method).
NOTE: Manual increment is kept on receiving a new Inbox message because that
one was reliable and it would have been more tricky to compute the new counter
for each target partner (mark as read is one user doing an action for himself,
whereas new message is from another user to potentially many different users).
Generic counter for threads is also not sent on every change for similar
reasons.
- Refresh Inbox automatically when some messages are marked as read and there
are more message on the server than currently loaded.
- Remove confusing (and impossible to maintain) counter on non-origin threads
(in particular channel followers). This behavior in JS was not consistent with
the server which always counted only origin thread (model/res_id).
task-2446302
closesodoo/odoo#65842
X-original-commit: f9bc1f98ed8f76846697cde68a760217b3af2aaf
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Currently, the subtype checked selection is not saved when the user adds and
removes subtypes. Indeed either an addition is performed, either a removal
but having both is not correctly taken into account when updating an existing
subscription.
How to reproduce
* click on the pencil icon to edit the subscription of the follower;
* as an example default "Discussions" will be the only one selected;
* check "Notes" and save;
* -> this works;
* click again on the pencil icon and uncheck "Notes" and check "Activities"
then save;
* -> this does not work as only removal is performed (Activities is not
checked);
The problem only occurs when you unchecked subtypes and checked other ones.
This commit fixes that behavior by taking into consideration both new
subtypes and subtypes to remove.
LINKS
Task ID-2205643
Task ID-2241688
COM PR #56775
X-Original-Commit odoo/odoo@d16b036638closesodoo/odoo#65605
X-original-commit: 18cb4f6d8120a30a7f5d05eef107ac1734dd1431
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Thibault Delavallee <tde@odoo.com>
Co-authored-by: Shahista Pathan <sat@odoo.com>
Add the currency symbol for the monetary tracking field to better
represent the change of a monetary field.
The currency will be fetch from the currency defined in the
monetary field or on the record's company in case there is not.
For example, if we have a record with a monetary field displaying
"$ 500". If we modify the currency and the value to have "450 €",
the message containing the tracking values will display:
"500 € -> 450 €".
We only use one field to track the currency of a monetary field.
Indeed, in the case where the currency is changed with the value
of a monetary field, only the new currency is tracked. We focus
on the fact that the more important thing is the new value.
Furthermore, when modifying a currency of a monetary field, the
user can already see the new currency before saving the changes.
This allows him to adapt the value of the field if he needs it.
(N.B. we assume that this case will happen very rarely)
Using only one field takes also into account that there are
millions of record for this model and adding a new field would
take a lot of memory.
odoo/odoo#61999odoo/upgrade#2060
task-2387268
PURPOSE
Reorganize and lint mail.channel code. Purpose is to ease future modifications
linked to groups and channels in mail / Discuss.
SPECIFICATIONS
Purpose is to better spot future query counter updates by ensuring current
thresholds effectively match runbot state. Some query counters for admin
are currently a bit lower than expected, probably linked to various ORM
improvements and cleaning done since last counter update.
LINKS
Prepares Task ID-2070632 (Discuss channel task)
Prepares Task ID-2419762 (SM channel task)
COM PR odoo/odoo#64862
We recently found a bug about generic internal subtypes not being correctly
propagated when doing auto subscribe.
For example: subscribe to a project, check an internal subtype like activities.
Auto subscribe done on project tasks should include actitivities subtype but
is currently not the case.
This test highlights the issue and a fix will be provided soon. In this test
we check both
* generic subtype propagation (comment- or activities- like subtypes);
* model-specific subtype propagation through parent relationship (like
following New Task on project to follow New on task);
* internal subtypes not being propagated to portal users;
* auto subscribe at create with both create and parent follower reasons;
LINKS
Task ID-2205643
COM PR #47336
X-original-commit: 1e29d48f5b10deca9ed7b991ea92ffc36f61c725
X-original-pr: odoo/odoo#47336
Co-authored-by: Thibault Delavallee <tde@odoo.com>
Co-authored-by: Priyanka kakadiya <pka@odoo.com>
Purpose of this commit is to move moderation tests directly into mail channel
test file. That way it is easier to maintain or update them as they are
linked to that specific model and not global to mail.thread.
Also containing
* remove unnecessary tests or merge tests belonging to the same category;
* make tests more readable;
Followup of odoo/odoo@e9571a4
Followup of odoo/odoo@1fadb3ec5d
Task ID-2421795
closesodoo/odoo#64501
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Notification may be sent using a generic mail.thread record, notably when
sending user notifications. In that case links to view document are
incorrect.
HOW TO REPRODUCE
Issue
- Install "Approvals"
- Submit new approval with you as "Request Owner"
- Click on "View Approval Request" in your mailbox
The link redirects to a 505 error
Cause
The model is not the correct one and the res_id is undefined
Solution
Specify the model and the res_id to _notify_get_action_link
when creating the link with kwargs
SPECIFICATIONS
Propagate message value through various notification sub methods. That way
we can rely on them if model seems void.
Also limit values given as URL parameters to some white listed values.
LINKS
opw-2358846
Task ID-2379766
Followup of odoo/odoo#60998
Followup of odoo/odoo#61545Closesodoo/odoo#63292Closesodoo/enterprise#15585closesodoo/odoo#64229
X-original-commit: 58bac5d242d6548d54f0163328fa64b319852e40
Related: odoo/enterprise#15634
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Achraf Ben Azzouz <abz@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
SPECIFICATIONS
Move channel tests from test_mail directly into mail module. Those tests do
not use models specifically introduced in test_mail. As those tests do not
target mail.thread features but rather mail models they can be moved into mail
directly.
LINKS
Task ID-2421795
COM PR odoo/odoo#63677
X-original-commit: 8c044735e8e30a80f85bd670eb61daba7645f62c
Thread search with `message_has_error` should only return threads containing
messages with failure of which the current user is author.
Follow up on https://github.com/odoo/odoo/pull/52403 that changed how
sub-queries were built. The current fix using `_search` is a non-ideal solution
until task-2366651 brings a new domain operator for this use case.
task-2409543
closesodoo/odoo#63231
X-original-commit: 337397eec5570fc9b3938d655a1ec0e4efcd73d9
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Message search with `needaction` in domain should only return messages with
`needaction` for the current user.
Follow up on https://github.com/odoo/odoo/pull/52403 that changed how
sub-queries were built. The current fix using `_search` is a non-ideal solution
until task-2366651 brings a new domain operator for this use case.
task-2388843
task-2389933
closesodoo/odoo#62753
X-original-commit: 209ed7c1991016054cbc4c5fc92ed30a07c4551d
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
WHY:
Some mail servers may provide `Message-Id` header in a section typed
`text/rfc822-headers` instead of a `message/rfc822`
According to https://tools.ietf.org/html/rfc6522#section-4 that section's body
actually contains the headers from the bounced email.
STEPS: a way to reproduce it should be using postfix v2.5+ with setting
bounce_size_limit=1. See
https://github.com/odoo/odoo/pull/42340#issuecomment-617605521
BEFORE: `bounced_message_id` is empty and thus the little email envelope icon
doesn't turn red, nor do the email resend features trigger in the UI. You could
be sending an invoice and never knowing it was bounced.
AFTER: bounces from mail servers that return the `text/rfc822-headers` part will
be handled properly.
---
@Tecnativa TT21170
opw-2162067
opw-2344252
closes#42340closes#62551closesodoo/odoo#62732
X-original-commit: 375ba5b37053a599922dd61c9e787553d6171291
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
This commit cleans the default_* keys of the context before creating mail.mails
and mail.notifications when notifying the record by email.
Without this change, there can be a collision when the ORM tries to compute
default values for the state field (for example):
- Model "A" has a 'state' field ;
- Create an action that redirects to model "A" form view, setting some default
values in the context such as {'default_state': 'done'} ;
- Model "A" has an inherit on 'mail.thread' and a 'user_id' field to set a
responsible user ;
- Model "A" record is created with a responsible user, who is automatically
notified by email that the record "has been assigned to him" ;
(see mail_thread#_message_auto_subscribe_notify)
- A 'mail.mail' is in turn created ;
- The 'mail.mail' model ALSO has a 'state' field, and the context is propagated
so the ORM will try to assign 'done' to that field, which is an incorrect
value ;
- -> Crash.
If we ensure that the default_* keys are cleaned from the context, the default
values computation of the mail.mail record will not be affected and everything
works fine.
A test was added to ensure this behavior.
Task 2393259
closesodoo/odoo#62589
X-original-commit: 6b6e546ac95d9acb2964121dd52aa2896d31bc33
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
As default is called numerous times with sometimes all fields, sometimes
only one field we have to ensure we avoid computing and setting unnecessary
or wrong values. We suspect this comes from default_get being called more
often at creation time since Odoo v14.
Default values for some fields in mail composer are dependent on each other.
Especially composition mode and model / res_id(s) are important for some
fields as behavior is not the same in comment or mass mail mode (subject
set / not set, template values rendered / displayed raw, ...).
Especially subject is wrongly computed in mass mail mode. For example use a
mass mail composer action on leads without template. Indeed a default_get
is called on subject alone. As web client adds active_model / active_id
automatically default returns a value for subject while it should not as
other values (model, res_id) are not asked and therefore not correctly
computed. It makes composer compute values in comment mode while it should
stay in mass mode.
In this commit we fix that behavior by
* computing only requested values (better match returned values and asked
fields);
* avoid computing values if context values are not given (model, res_id or
res_ids, composition_mode);
Task ID-2390314
PR odoo/odoo#62061
X-original-commit: 1c8ca358d75c9fe00631731d5061674c0a3a040b
Some tests are currently dependent on bus state when computing number of
notifications sent. For example install Crm then test_mail_full. Some
tests crash as too much notifications are found in the bus.
We therefore clean remaining bus notifications before running tests to
ensure we check notifications during test itself. This make tests more
easy to reproduce.
Task ID-2390314
PR #62061
X-original-commit: 92ff1379b0492765fd0ba9863a9ce13fba7eeb4a
Purpose is to have some low level tests for composer itself allowing to
ensure its behavior. We add tests notably about default values computation
in mass mailing mode as well as template_id change and values synchronization
in composer model.
In a near future composer will probably be improved (use computed fields,
rewrite part of its logic to improve performances). Having tests done before
those tasks ensure we notice every change that might happen.
Task ID-2390314
PR odoo/odoo#62061
X-original-commit: def98d2375a8a906092293f0aa1ce03bf948d2d3
This reverts commit fbd30f4266d86b53aa4b13b72a93bccee0d7eb69. Indeed kwargs
are used to build a link, meaning message value are given to some links when
using message_notify.
A better fix will be provided soon. Reverting to avoid issues in stable.
closesodoo/odoo#61632
X-original-commit: e861f7294a7bd6bde056b987f15e48df4b0ab877
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Issue
- Install "Approvals"
- Submit new approval with you as "Request Owner"
- Click on "View Approval Request" in your mailbox
The link redirects to a 505 error
Cause
The model is not the correct one and the res_id is undefined
Solution
Specify the model and the res_id to _notify_get_action_link
when creating the link with kwargs
opw-2358846
closesodoo/odoo#61478
X-original-commit: 075325226d6f7c2af638013f25613ddd391e506b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
Purpose
=======
Make the "activity_state" searchable on the "mail.activity" mixin.
This field is not stored as it depends on the current time.
Technical
=========
To make the search, we perform a SQL query.
The "activity_state" depends on the state of each activities on the
record. And this state also depends on the timezone of the user of
the activity. That's what made things tricky and we need to make the
conversion in SQL for performance purpose (we can not fetch all records
and compute them in python).
There's a special case, where there's less than 24 hours between the
deadline and the current time but one day of difference. In that case
the state should be "planned" and not "today". This case is handle by
the function "DATE_TRUNC" (e.g. 23h 01/01/2020 & 1h 02/02/2020).
Also for performance purpose, we compute the delay only once and we use
the function "SIGN" so we can use a switch/case instead of duplicating
3 times the expressions.
Task 2354754
closesodoo/odoo#60074
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is simply to add tests about alias defaults.
Code protects it against being badly formatted. However having
tests ensuring it is always a good idea to avoid regression.
Task ID-2361179
closesodoo/odoo#60026
X-original-commit: 0075cc02f9a11dcddaf9ca7d70cc1adf7596f6d3
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- channel_seen is now called even for own message and only when needed
- channel_seen is now called with a message_id which transfer the
decision of what is seen to the client which makes more sense
task-2282235
task-2282248
closesodoo/odoo#57956
X-original-commit: 04edfa50ccea305050d017c4a1996e561bc7bd57
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Thibault Delavallée