Backport of `_get_guest_from_context`.
Prevent crash when unexpected (not recordset) values are in the context.
Ensure the mere existence of a value (example integer) does not lead to
executing flows where an actual guest is expected.
task-2819597
closesodoo/odoo#127831
X-original-commit: 3d1890e88b99f059377d8b227b56d77798157397
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, when posting a message with 3 attachments
`A B C`, the message displayed attachments in order `C B A`.
This happens because message format list attachments in order
of `message.attachment_ids`, which has no specific order.
This commit fixes the issue by ordering attachments in
`message_format` from the oldest to most recent, so that displayed
order in message matches the one from composer, which itself
matches the order of creation of attachments.
closesodoo/odoo#127830
X-original-commit: 53508effa66bca79aa872412333ca8578ca9b813
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
In [1] the order by `id ASC` has been removed from the
`_message_fetch` method. This is wrong since we want
to load the messages coming DIRECTLY after the given
id thus, this order is required.
In order to solve this issue, this commit ensures the
order of the messages returned by the `_message_fetch`
method is always in descending order as it was done
implicitly before [2].
[1]: https://github.com/odoo/odoo/pull/123664
[2]: https://github.com/odoo/odoo/pull/116666
task-3349175
closesodoo/odoo#124169
X-original-commit: 074a5fea5a7f08c7018620cb9b2b956b3a871344
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Didier Debondt (did) <did@odoo.com>
Since [1], messages were ordered in ascendant order if the
`after` parameter was passed to the `_message_fetch` method.
This leads to messages being inserted in the wrong order
when several messages are batched then fetched via the
`/thread/messages` route. In practice, this order can
be removed since the `/channel/messages` route already
orders its messages correctly.
1: https://github.com/odoo/odoo/pull/116666/
task-3349175
closesodoo/odoo#123727
X-original-commit: 597b0b00068f6ab99632563faeb2ea18f5c9056f
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
'legacy' parameter was present only for a specific part of attachments
formatting. It was used only for portal, as the widget used in frontend
was not using the 'discuss' orm-like convention.
As portal formatting is now independent from mail/discuss formatting this
can be safely removed, simplifying the API.
Task-3322905
Part-of: odoo/odoo#121104
Allow users to unfollow easily document from the inbox for which he/she doesn't
want to be notified anymore.
When hovering on a follow up message with a related document followed by the
user, the interface displays an action to unfollow it that allows the user to
remove himself/herself as follower of the document. As a result of performing
that action a toast is displayed as a feedback.
Technical note:
The unfollow link is displayed on a message.canUnfollow is true which check
that the thread related to the message is followed by the user.
In order to know if the user follows the record related to the message, we now
transmit with each message the id of the follower table that link the user to
the related record if it follows it. This allows to insert the follower on
client side so that the unfollow action can use the standard mechaism already
developed to unfollow a record.
Unfortunately, that information coudn't be added in the already public method
message_format of mail message because that method is not always called on the
user retreiving the message but also by the one posting message. We didn't want
also to include all followers in the formated message so we rely on additional
method that add that information per partner.
To support unfollowing a document in the inbox no matter the current company,
we have modified message_unsubscribe in mail_thread to allow internal user to
unsubscribe themself without checking any rights. Indeed, some document have
record rule that prevents reading it if the user is not in the right company
(ex. crm.lead) and then was preventing the user to unfollow the document using
that method.
Task-3061864
Part-of: odoo/odoo#107978
Currently some auto_reply templates are internal as a means to prevent
notifying users everytime we send a reply to somebody.
This raises the issue that since responses to internal notifications
are themselves internal notifications, often nobody will be notified of
responses to these automated messages.
We fix this by marking these messages as auto_comments, which will
ensure responses to these messages are
considered non-internal (and thus 'discussions', by default).
task-2834304
closesodoo/odoo#94018
Related: odoo/enterprise#35466
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
By this commit, If a user edits the message body or changes
the message attachments, the edited label in the blob,
shows the last edit Info.
Task-2664848
closesodoo/odoo#117896
Related: odoo/enterprise#40208
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
The opportunity is taken to clean the methods to make the override
actually possible.
Part of task-3265211
closesodoo/odoo#119942
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit focuses on removing all references to discuss.channel from
code located in /models of mail module.
In preparation of splitting discuss and mail modules.
Part of task-3265211
closesodoo/odoo#119413
Signed-off-by: Debondt Didier (did) <did@odoo.com>
* = bus, calendar, crm_livechat, hr, hr_holidays, im_livechat, mail_bot,
mass_mailing, privacy_lookup, test_discuss_full, test_mail,
test_mail_full, website_crm_livechat, website_livechat, base
In preparation of splitting discuss and mail modules.
Part of task-3265211
closesodoo/odoo#118354
Related: odoo/upgrade#4553
Related: odoo/enterprise#39661
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Lot of override of read_group reimplement partially custom security
rule of `_search` method. In order to simplify these security check
and have a consistent behavior between the search and read_group method,
_read_group now use _search to create the from and where clause.
Part-of: odoo/odoo#110737
With this commit, messages can be pinned on a channel and
chat conversation. There's a new menu listing all pinned
messages on a conversation, and we can jump to these messages
in the current conversation.
As this feature incentives to see older messages, this commit
also adds a "Jump to Present" button when looking at old messages.
closesodoo/odoo#116666
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Adapt code of message fetch so that fetching of
(needaction) messages are controlled in a way to
keep continuous sequence of messages at all time.
This code design solves the "holes" problem in a message
list by not allowing holes. This fixes many scenario that
generated these holes, resulting in unfetchable messages.
Example of such a scenario:
- post 40 messages
- post a new message that is reply of the oldest message
- page reload and scroll up until load more
=> 10 messages are missing in-between replied message and
following message (that should have been 11 messages apart)
This code also prepares for allowing jumps in a conversation.
Part-of: odoo/odoo#116666
Before this commit, the portal user get a Access Error.
After this commit, the portal user see the chatter without error.
The code works with reaction browsed in sudo, but since we use a ior
with a record not in sudo, we loose the sudo flag and so the right for
portal user to read it.
```py
x = record.sudo()
y = record
x |= y -> (x, y) in sudo
y |= x -> (x, y) not in sudo
```
How to reproduce ?
Assign lead to a portal user
Post a message with another user like demo on the lead
Add reaction with the admin user
Open the opportunity on the portal with portal user
-> access error
opw-3215507
closesodoo/odoo#117313
X-original-commit: 2bde53541b7a0171c7d1b89e0e412d624f5eab37
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Jérémy Kersten <jke@odoo.com>
If applied, this commit will solve the keyError for _invalidate_documents.
Before this commit:
============================================
KeyError 'rating' or 'False' occurs when a user tries to send a message and
_invalidate_documents() takes the parameter model equal to 'rating' or 'False'.
but the model 'rating' is not available in the database and It will be accessed
by the self.pool[model].
After this commit:
============================================
Solved the issue when the model 'rating' is not available or the model is 'False'
while sending a message.
sentry - 3956327451
closesodoo/odoo#116302
X-original-commit: 5becbca6531d5829bee262a5c1b64ae5e0917f8e
Signed-off-by: Anh Thao PHAM <pta@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
RATIONALE
Activity report is slow, as it makes a complex query inside mail.message table
which is one of our biggest table with crm.lead table, also a big table. This
activity report could be speeduped by looking only on activities, not including
discussions messages.
SPECIFICATIONS
Index on "mail_activity_type_id" field of <mail.message> is updated as main
searches include a not null on mail activity type id field.
Task-3129356 (Crm: Fix activity report performances)
Part-of: odoo/odoo#112535
When creating a <mail.message> with attachments a manual check is done on
given attachemnts to ensure user have rights to read them. Indeed otherwise
user could simply give attachments from a protected document when posting
on a document he can read and try to gain information about those.
However sometimes user can post and create messages without having read
access on the document, e.g. when being notified and answering in a multi
company environment.
In this commit we consider that creating a message with attachments linked
to the same document does not require an additional check for attachments.
The check is performed at message level (see its custom 'check_access_rule')
and is considered sufficient. However attachments linked to other documents
using model and res_id are still checked.
This fix helps greening the 'test_post_wo_access' test recently introduced.
Task-3213982 (Mail: fix 'multi-company' post support)
X-original-commit: odoo/odoo@bab0549904
Part-of: odoo/odoo#114511
This is about the overrides of _search() on models mail.activity and
mail.message, which both make extra queries to implement their specific
access rights. We combine both queries made in _search() to retrieve
accessible records. This simply uses the API of the Query object to
retrieve the data that is necessary to restrict access to messages.
Move security check outside of _message_format() for performance. The
call to check_access_rule() inside _message_format() was redundant in
many cases and generated more SQL queries than necessary.
Also for performance, accessing fields from records should not actually
check permission. That's a bit freaky, but this reproduces the former
behavior of mail.message.
And finally, make method check_access_rule() on mail.message check
ir.rules, in order to make it consistent with method _search().
Part-of: odoo/odoo#112126
Goal: make _search() always return a Query object, in order to make
search_read() in a single query when possible
Adapt the overrides of _search() towards the given goal.
Part-of: odoo/odoo#112126
The parameter in search() is redundant with method search_count(), and
was making the calls less readable.
The method _search() is aimed at always returning a Query object. The
method can therefore never return an integer, hence the removal of the
parameter. This does not actually remove any functionality from the
method; counting result is simply given by using it differently.
Part-of: odoo/odoo#112126
Bug
===
When we remove some mail messages, we invalidate the cache of the
related documents. But in the same loop we call _invalidate_documents
which invalidate the cache, and so at the next iteration we will need
to make a new SQL query to know if the message is a "thread message".
So because of the prefetch ids, and because we invalidate in the loop,
if we unlink 1000 message, we will make 1000 SQL queries to fetch the
fields values of the 1000 messages.
Note that the unlink method will invalidate the entire cache anyway,
so unlike the write / create methods, we shouldn't need to invalidate
manually the related documents.
Task-3171093
closesodoo/odoo#112494
X-original-commit: f8958e9bbd4c7c37f614b20f7ed4d4825d438362
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Followup of odoo/odoo#95623 (introduce scheduled message notification) as well
as odoo/odoo#99482 (support scheduled datetime from template to composer in
both comment and mailing modes).
Task-3093257 (Mail: The Composer Update)
Part-of: odoo/odoo#107356
In some cases, a given user may create a message in behalf of other people.
This happens for example
* when calling message_notify to send notifications in a given flow, while
setting author_id to someone else (e.g. appointment flow who send invite
as notification, using the event responsible as author);
* when using templates with email_from set which may update the author_id
to match the email_from;
Notably with message_notify the current user may create a message he cannot
read afterwards, as he is not the author (as in 'author_id' field value)
and cannot read the message even with access on related record (as it is
a 'user_notification').
In this commit we relax a bit the 'read' rule on mail.message to allow reading
a message the user created.
Task-3093257 (Mail: The Composer Update)
Part-of: odoo/odoo#107356
Purpose of this commit is to clearly check input of ``message_post`` method
and its main helpers in order to prevent wrong usage of message post API.
Some values used to populate message fields should not be set directly when
posting or logging messages. Indeed they may be part of other process (like
notification process managed by ``_notify_thread``, or could be setup by
custom routes like 'reaction_ids', or custom usage of 'model' and 'res_id'
that could conflicts with record on which methods are called).
We therefore add checks and cleanup in those methods to be sure the API
is used as intended and avoid unwanted side effects.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
All emails sent from the chatter start with "Re:" followed
by the name of the record. The name of the record alone is sometimes not enough for
the followers to understand what the mail is about.
Additionally, "Re:" does not make sense when starting a conversation.
This commit gives better default subject
for event registrations and allows thread models
to override the default subject of messages.
This also removes "Re:" from default mail subjects.
Task-2833215
closesodoo/odoo#95817
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
The field `notified_partner_ids` has type Many2many with relation table
`mail_message_res_partner_needaction_rel` [1] which is a regular Odoo model
`mail.notification` with some extra fields. One of those fields is required:
`notification_type`.
On copying `mail.message` record, ORM copies Many2many fields directly without
using `default_get` method for `mail.notification` model. Particularly,
`notification_type` get null value and we get an error.
STEPS
1. Create Server Action for `mail.message` model:
```py
for message in (records or record):
message.copy({
"subject": message.subject + "(SA copied)",
})
```
2. Add contextual action
3. Open `mail.message` which has non-empty value on
`notified_partner_ids` (*Partners with Need Action*)
4. Run the Server action via Action menu.
PROBLEM
```
ValueError: <class 'psycopg2.errors.NotNullViolation'>: "null value in column
"notification_type" of relation "mail_notification" violates not-null constraint
DETAIL: Failing row contains (11, 210, null, 3, null, null, null, null, null,
null, null, null, null).
```
SOLUTION
Fix it by adding `copy=False`, because we don't want to copy those values
anyway (confirmed by TDE).
[1]: The relation table is renamed to `mail_notificaiton` in v15+
opw-3069556
closesodoo/odoo#108599
X-original-commit: d68b0f7d6b8f973ddaafdd7526d4f753a1b6abd2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
When a record was deleted, the related messages were remaining in discuss
front-end causing an error when the user was clicking on them. This solves the
problem by removing messages in the front-end as soon as they are deleted.
Task-2960281
Part-of: odoo/odoo#99371
* = bus, hr_holidays, test_discuss_full
- use channel member instead of partner for typing
- use channel member instead of partner for all other return values from server
- remove temporary partner hack in livechat and keep public partner
- remove some obsolete convert data
- adapt format methods accordingly
task-2664853
closesodoo/odoo#98923
Related: odoo/enterprise#30760
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
We now return generated records when calling ``_action_send_mail`` on mail
composer. This allows to have access to generated emails (in mass mode) or
posted messages (in comment mode). Otherwise we have to access sub-fields
like activity_ids / message_ids, which may be inefficient or generate extra
ACLs checks.
Also replace some |= with += when usage of OrderedSet is not necessary. To
keep ordering, ordered sets are used when doing an or between record sets.
However in some cases we know we are simply adding records not already in
a previous record set, meaning we can just use +.
Task-2883589 (Activity performance and cleaning)
Part-of: odoo/odoo#93682
Purpose
=======
Move the code which updates the mail message from the message model to mail
thread. Most other thread methods (like `_message_update_content_after_hook`)
are defined at record model level. It makes sense to delegate the update to
documents and not to the message. Message is a low-level technical object
that should not really hold business code.
While modifying this code, an update is done in the update content. We now
also allow to update the body without removing all attachments.
Finally tests are added as this feature was added without really testing
model code.
Task-2207626 (Rating: Delay rating notification to ease feedback)
Part-of: odoo/odoo#95623
Co-authored-by: Thibault Delavallée <tde@odoo.com>
* = calendar, im_livechat, rating, snailmail, test_discuss_full, test_mail,
website_livechat
Distinction between "replace" and "insert-and-replace" can be guessed based on
the type of the provided data.
task-2957295
closesodoo/odoo#98404
Related: odoo/enterprise#30580
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Current behavior
Starred messages counter takes into account the starred messages of a private
channels even if we no longer have access to this channel. Happens with deleted
messages too.
Steps channels
- Install Discuss
- Create a Private Channel and invite Marc Demo to join it
then send him a message
- *As Marc Demo*, star the message then leave the channel
-> Starred counter still shows 1
Steps for deleted messages
- Join the private channel again
- Delete the starred message (with Mitchell Admin)
-> Starred counter still shows 1 for Marc Demo
Reasons
Starred message count is computed by a raw sql [1] which only counts partner's
occurrences without taking into account the message's state and/or the
associated channel.
Side records (stars, notifications) are not removed when emptying a message
content [2].
With changes
- It doesn't take into account messages from a private channel which we no
longer have access to by doing a search on mail.message instead of doing it
in SQL (which filters out invisible messages);
- It correctly voids side records when emptying messages;
Side effects
This somehow raises number of queries because we now check access on messages
and records. However this is necessary as bypassing ACLs means unreachable
notifications or stars.
OPW-2742092
Task-2813738
[1] : https://github.com/odoo/odoo/blob/2c1c6b1373c238216fda1e2d9d2f00b5d16c8ca3/addons/mail/models/res_partner.py#L49-L51
[2] : 776d1ee08bclosesodoo/odoo#97974
X-original-commit: b1e8f7d97e3a1fa624436d2dd6801bf5fe7d19aa
Related: odoo/enterprise#30415
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
This removes an extra request, targets fetched messages more reliably and
simplifies the code.
task-2847909
closesodoo/odoo#96840
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
In module mail, invalidating 'message_ids' on a mail thread also
invalidates its inverse field 'res_id' on messages. If you haven't
flushed it before, your cache will be inconsistent, as shown by the test
/mail:TestMailgateway.test_message_process_bounce_records_channel.
In module purchase_stock, add depends on report.stock.quantity. This
ensures that when the model is queried after changes in other models,
the data on which the SQL view depends is flushed to the database before
querying that model's table.
closesodoo/odoo#66938
Related: odoo/enterprise#16722
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
This commit mainly fixes an override of ``_message_compute_author``. It is
done with an incorrect default parameter value for raise_exception defaulting
to False instead of True). By the way we also fix parameter naming in order to
ease understanding.
Part of Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#94660
Prepare an informative and nice-looking preview from the main content of the
email body, avoiding buttons/images alt etc.
Links, images, tables are removed.
Whitespace is added after the preview to avoid including the full message in
the preview (with markup).
Tags and attributes are also added to increase compliance with HTML5 standard,
including accessibility.
One additional SQL request is required to fetch the preview sub-template.
Task-2413355
closesodoo/odoo#86266
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Change all masculine nouns in Odoo's code to neutral nouns (when
possible), making sure that demo data is correctly handled. This is
particularly important since our code is open source, and nowadays lots
of machine learning models are trained on open source repositories.
With this small change we contribute to training more "fair" models, and
teaching models that "employee" or "user" != "he".
This also affects some text visible by the user, hence making it more
inclusive for Odoo users.
Task-2853046
closesodoo/odoo#91292
Related: odoo/enterprise#27302
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Sébastien Theys