Purpose of this commit is to avoid conflicts when creating new followers
with existing context keys. Indeed some actions may propagate a default
partner id or channel id that is not wanted. Example if when inviting someone
on a slide.channel in eLearning, a default_channel_id is set in context
that clashes with follower creation, thinking it is a mail.channel.
Task 2067872 (eLearning internal testing)
PR #36756
Before this commit, when user follows odoobot chat onboarding and
sends a canned response at the canned response step, odoobot did
not validate the message with the canned response.
This is caused by RPC `message_post` that filters out values that
are not message fields, such as `canned_response_ids`.
This commit fixes the issue by adding a non-stored field
`canned_response_ids` to `mail.message`. This requires the reverse
relation too, `message_ids` in `mail.shortcodes` (= the model for
canned responses).
Task-Id 2058455
closesodoo/odoo#36411
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
In resend wizard tests
In some cases tuple comparison of states seems to fail. Indeed order seems
to change in some cases depending on installation order. With this commit
we correctly check partner / notification status one by one, avoiding
to rely on order / set length that is not guaranteed.
In mail gateway tests
Add a specific order on name to be clearer about what we mean when fetching
users as a fallback, until better heuristic. Using name is sufficient as
we have no need to rely on complex partner display_name.
Task 2060220 (testing SMS integration)
PURPOSE
Currently mailgateway runner user is used to create most documents through
incoming emails. Purpose of this commit is to try to link document creation
and update to users, using the email to make the matching.
SPECIFICATIONS
New sudo implementation allow to bypass access rights while keeping effective
user as creator. Use this mechanism to create documents still using the
mailgateway runner user while linking creator to matching user.
Heuristic to use to match email_from and users
* if route is linked to an alias: check its owner record and check in its
followers;
* find users having this emails;
* if route is linked to an alias: use alias_user_id field;
* fallback on mailgateway user;
Other side effect is that creator and author of incoming email linked to the
new record will now better match the document creator when linked to an
existing user.
LINKS
Task 1919267
PR #30597
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to lessen complexity of stack chain in mail main
methods. Removing decorators is a good start for this.
LINKS
Task 1919267
PR #30597
Because of a whitespace character present at the beginning of the message_id of some mails,
they were fetched twice.
From the SQL side, we see that Outlook is formatting the header following the RFC822
by allowing the header to look like:
Header:<CRLF>
<whitespace><hash_of_msg_id>
From RFC822:
"Each header field can be viewed as a single, logical line of ASCII characters.
For convenience, the field-body portion of this conceptual entity can be split
into a multiple-line representation" (abr.)
It was also possible to find out by checking the logs.
One or two whitespace(s) can be seen before the hash of the msg_id.
The following commit is making sure we use and save the message_id without the whitespace
by stripping them off on the coming mail.
OPW-2006806
Applying CHS solution to avoid crash on empty header.
closesodoo/odoo#35682
Signed-off-by: bve-odoo <Abridbus@users.noreply.github.com>
Since #32404, the fallback case where we have no recipients and no parent_id
on message notify has a typo on mail_message. A user will receive a traceback
when using compose message wizard on a record not inheriting from mail_thread if
he forgot to add recipients.
If the typo should be fixed, notifying the user that no recipients were found and thus,
message_notify won't do anything could be interresting. We can raise a UserError
to give a more explicit failure reason.
We would like to avoid to raise this error on a low level like in message_notify
to avoid to break mail_gateway mechanism, but raising it from mail.compose.message
send_mail shouldn't have any side effect.
We can simply check the output of message_notify to know if something was done
to avoid to duplicate logic used to define recipients.
task-2046180
closesodoo/odoo#35378
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
This commit allows a livechat operator to send a chat request to a
connected and available website_visitor.
A visitor is considered as connected if his last tracked website.page request
was within the last 5 minutes.
A visitor is available if he doesn't have an active livechat conversation
(mail_channel with type = livechat).
- If another operator sent him a chat request
- Or if the visitor asked himself to speak with an operator
(via the normal and existing flow)
A livechat conversation is active while the visitor haven't left the conversation.
An operator cannot leave a livechat conversation, only the visitor can.
The flow to send a chat request:
- On the visitor view (tree or form), operator click on 'send chat request'
(button or livechat icon)
- A empty conversation with the visitor pops up at operator side.
- While the operator didn't send a message, the visitor won't see the conversation.
- The operator can type a message to the user
- If the operator close the chat without sending any messages,
the chat request AND the mail_channel are both deleted.
In this case, the visitor is then available to send him a new chat request.
- If the operator send a message, at the visitor's next action
(page navigation on pages that allows livechat, based on livechat rules),
the conversation will pop up at visitor side, using the livechat button widget.
The visitor won't be able to request a livechat conversation with an operator until
he leaves the chat requested by the operator.
- Once the visitor leaves (with or without rating) the conversation :
- the operator is notified that the visitor has left the conversation
- the chat request is deleted to keep the chat request table clean and minimal
- the livechat conversation if set to inactive.
- The visitor is now available again to send him a chat request.
This feature uses the already existing livechat_session cookie mechanism,
so no further code modification was needed to make this work.
It's directly integrated is existing livechat flow.
The chat_request model is only useful to quickly check if a visitor has a chat request
and to send the livechat conversation info to the visitor via the livechat_session cookie.
This commit also add a website_visitor banner info on discuss view :
To be able to quickly see all the relevant information of a website visitor
while talking with in discuss view, a fixed banner have been added.
Only the discuss view will benefit from this because detached chatter window
is to small to display such banner.
Task ID: 34624
PR #2028059
When duplicating a record, the language is set to None in the context
when copying a record
new = self.with_context(lang=None).create(vals)
self.with_context(from_copy_translation=True).copy_translations(new, excluded=default or ())
In mail.thread, the usecase of no language in the context was considered
if 'lang' not in self._context:
track_threads = threads.with_context(lang=self.env.user.lang)
but not the case of a language explicitly set to None
This means that, when duplicating a record, the tracked fields mesages
were untranslated.
Fixesodoo/odoo#35213Closesodoo/odoo#35331
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Follow up of 61de1c263a
- Remove the dangerous **kw from the route in favor of specifying useful args.
- Use the existing method to link attachments to message instead of duplicating
the logic in an incomplete manner.
- Fix an issue where the actual email would not be sent if the message was empty
but an attachment was defined.
- Ensure the send attempt is done immediately instead of after the cr commit.
The goal is to show potential error messages correctly to the user with the
crash manager instead of a generic error page.
This also increases the send timeout and prevents the error in the first
place in most situations.
closesodoo/odoo#35263
Signed-off-by: Christophe Simonis <chs@odoo.com>
PURPOSE
Allow quick message creation by allowing create multi on mail.message.
Also introduce a new helper tool method to log in batch on records.
SPECIFICATIONS
Purpose of this commit is to add a way to log notes in batch on a document.
Those notes are logged without any notification mechanism, allowing to
attach a note in as few queries as possible.
This is implemented by
* allowing create multi on mail.message. Nothing changes in its behavior
except that it is not working on a list of dictionaries;
* adding a ``_message_log_batch`` tool method allowing to post a batch
of notes on records;
* adding a tool method to correctly find author / email_from, to be used
in various message_post / log / notify methods in order to have the
same behavior in all those methods;
Logging in batch will soon be used in SMS when attaching a note to sent
SMS without having extra notifications. This will be used notably when
performing mass SMS without using the standard notification mechanism.
LINKS
Task 1997464
PR #34424
Original SMS addition: Task 1922163 (4287481)
PURPOSE
Add some improvements in mail gateway: remove private discussion, improve
bounce management, allow resetting bounce counters, improve automatic set or
reset of blacklists and ease mass mailing inheritance.
SPECIFICATIONS
The number of message bounce is incremented each time the email bounce
on a specific email address. To have a correct information, we should
reset to zero this counter if we receive a mail from this address.
Indeed, if we receive an email from an email address, this email is
active and the message bounce number (if > 0) is not relevant anymore.
Only models inheriting form blacklist are impacted by this improvement
in order to limit a bit side effect.
Also, add a check in autoblacklist rule. No need to check the stats
if message_bounce is < 5.
This commit introduces
* ``_routing_reset_bounce`` routing method managing the bounce reset;
* ``_message_reset_bounce`` model method that resets bounce counter
in blacklist enabled models;
LINKS
Related to task ID : 1893155
Linked to PR #33340
PURPOSE
Add some improvements in mail gateway: remove private discussion, improve
bounce management, allow resetting bounce counters, improve automatic set or
reset of blacklists and ease mass mailing inheritance.
SPECIFICATIONS
Purpose
* move bounce information detection in message parsing. It allows to have
this information available in various steps of routing instead of having
to manually re-compute them;
* handle bounce in specific methods allowing easy override;
* improve bounce management, notably when detecting a bounce not linked
to the bounce alias configuration;
* better integration with blacklist mechanism;
Specifications
* compute bounce information in ``_message_parse_extract_bounce``.It parses
bounce information and returns a dictionary allowing to update parsed email
values;
* remove override in mass_mailign that basically does what mail already
does;
* manage bounce in ``_routing_handle_bounce``;
* when detecting a bounce, correctly call the bounce management method on
all models inheriting from blacklist;
* correctly update bounce counter;
* bounced mailing traces and automatic blacklist in mass mailing should
be done in ``_routing_handle_bounce``;
* add some tests;
LINKS
Related to task 1893155
Linked to PR #33340
PURPOSE
Add some improvements in mail gateway: remove private discussion, improve
bounce management, allow resetting bounce counters, improve automatic set or
reset of blacklists and ease mass mailing inheritance.
SPECIFICATIONS
Parsing email values: make message_parse effectively prepare all required
values for later processing
* update message_parse to add some more data directly in parsed dictionary
and avoid having to parse value again in later processing and computation.
* notably recipients computation is now done directly in parsing. It
includes email check and reconstruction using tools methods. That way
routing just has to handle those values and not compute part of them;
* from and cc are correctly managed with parsed and cleaned (sanitized)
versions in dictionary;
* remove all code decoding message header and replace them by fetching
the parsed value instead;
* filter parsed values before calling message_post to ensure right values
are given to it instead of having to manage them in message_post. Indeed
caller has to give the right input;
* make parsing sub-methods (extract payload, post process payload) have
a dictionary as input and output to always manage a dictionary of values
through the parsing methods and update their namespace;
Routing: remove deprecated code parts
* remove use of email_references regex. Indeed emails are routed using their
messageId and not the regex anymore since several versions [1];
* clean some unnecessary variables;
* simplify variable type input, like message_parse accepts only valid
email.message instances and to avoid several decode / encode. Tests are
updated accordingly;
Update docstrings of those methods.
LINKS
Related to task 1893155
Linked to PR #33340
[1] See df037e2959 and 0028c42136
PURPOSE
Add some improvements in mail gateway: remove private discussion, improve
bounce management, allow resetting bounce counters, improve automatic set or
reset of blacklists and ease mass mailing inheritance.
SPECIFICATIONS
Purpose: clean mail gateway code by cleaning message_route_verify
``message_route_verify`` is therefore renamed to ``_routing_check_route`` as
there are already some methods prefixed by routing, related to email routing.
This method is also made private as it has no real use for external world.
Parameters of this method are also cleaned. Various cleanings and code
improvements made some parameters not necessary anymore :
* create_fallback: was always True;
* update_author: was always True;
* drop alias: no real use as aliases are used to compute the route and its
access, dropping it at that point has no effect on code;
* assert_model: renamed to raise_exception to be more coherent with the
same kind of parameter used in Odoo;
LINKS
Related to task 1893155
Linked to PR #33340
PURPOSE
Add some improvements in mail gateway: remove private discussion, improve
bounce management, allow resetting bounce counters, improve automatic set or
reset of blacklists and ease mass mailing inheritance.
SPECIFICATIONS
Private discussion support in mail gateway means having incoming messages
not linked to a document. It means having a void model and res_id on related
messages.
Old private conversations in Odoo were implemented using messages not linked
to any document [1]. It was possible to send an email to some people through
the UX and they were able to answer it. Messages were not attached to any
document and model. There were some limitations to this feature, notably it was
limited to replies (no beginning of private discussion through mail gateway).
One way of doing it was through the use of res.users aliases [2]. There was
also a vaguely twitter-lite use of chatter on HR employee profiles linked
to users aliases, then removed with an explicit support of private
discussions [3].
It is not supported anymore since discussion between users is now done using
chat. Aliases on users have since been removed [4]. Contacting partners or
customers can be done on business documents or on channels. Simple email
discussion is not supported in Odoo as it is not the purpose of mailgateway.
This commit removes code related to private discussion in mail gateway and
some specific support in message_post method.
LINKS
Related to task 1893155
Linked to PR #33340
[1] History is a bit messy, see notably fd90140d7b and commits around
[2] User alias addition 052f2ace57
[3] End of employee twitter-like and posting on users = private discussion 89896f32bb
[4] User alias removal 029d1baf35
The purpose of this task is to add a visual indicator on kanban and list
views when there is an exception activity on a record. To do so, two
fields have been added on the activity mixin that determine if the record
has an exception activity and its corresponding icon.
When there's an exception activity, the next activity icon is different
in the kanban and in the list view, the icon is displayed at the end of
the column with no label.
Prefetching all activity_type_ids in compute will allow to lessen
queries (3 query for this compute) and cache may benefit to other
mail.activity.mixin computed field, like activity_state in kanban view
Task 1889379
This attribute is misleading as it is insufficient to correctly upgrade
the database. It only renames the column in the database, but other
operations are needed, like updating the corresponding `ir.model.fields`
record (and its xmlid). The default values and the translations are also
lost during the upgrade.
Moreover, this feature was misused. It was:
- left on fields during multiple versions.
- used on reports (SQL views). This would be ok if the feature was
complete, but, as is, it was useless.
- kept unchanged after a second renaming of the field (which can happen
versions later the first rename).
- used, even when the meaning of the field changed. i.e. the field
`archived` has been renamed to the classic `active`, but the value
in the database should be switched.
This gc option should delete more notifications: we only keep notification
not send, and set inbox notification as sent.
closesodoo/odoo#30067
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
mark_all_as_read is using notified_partner_ids to filter
the messages to use. But anyway, the notification will
be filtered on partner right after that.
Since if we have a domain, the message set will be quite small,
(scope of a thread) we search all those messages.
If not, we actually avoid to search on message and go right
to the notifications.
Reading the message_ids will garantee to have the minimal
set of message that where actually passed from unread to read.
Since data should not be in cache at this time and mark_all_as_read
is usually called alone, we prefer to use cache and perform a read
immediatly.
Task-ID 402597
notified_partner_ids, (previously notified_partner_ids) is used to
populate a list of partner to prefetch + return a list of partner_ids.
1. the list of partner_ids is doesn't look to be used, and thus
can be removed. Was introduced in 1d4dbc3440
2. Prefetched list of partners is used to generate customer_email_data.
Since this list is limited to partner email notifications , we can use
a custom search instead.
The proposed implementation is far from perfect but proposes the minimal
changes to remove notified_partner_ids, without (hopefully) negatively
impacting performances.
Task-ID 402597
,*:crm, website_blog
The mail.message needaction_partner_ids meaning changed over time,
and doesn't actually reflect the list of partner in needaction.
More than that the message_format needaction_partner_ids used by js
began to diverged from mail.message field since 19fb650863
To avoid any confusion, renaming it to notified_partner_ids will help
to avoid confusion between python and js meaning, and reflect the actual
content of this field : a list of partner that where notified once on
this message. This field is mainly usefull for testing.
Task-ID 402597
This commit adds a new mailbox in the Discuss app called 'History'.
Messages that have been marked as read are moved to 'History'.
Notifications are required to link history messages to users. So
notifications are now deleted after they are more tha 6 months old.
This means History mailbox keeps less than 6 months old messages.
Note that this feature only works when user notifications are handled
in Odoo. This can be set in the user preferences, under the
"Notification Management" section.
Task-ID 402597
This check was introduced with d82b897ea1 in 12.0 where `get_base_url` was
not yet a model method.
Since f727cd2645, in saas-12.5, that method is now on model, making the
`hasattr` check useless.
closesodoo/odoo#35057
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The big images are probably never going to be used for the following models:
- pos category
- fleet brand
- livechat channel
- mail channel
- payment acquirer
And if big images are needed some day the model should use image.mixin instead.
PR: #34925
image_original => image_1920 (now resized to 1920)
image_big => image_1024
image_large => image_256
image_medium => image_128
image_small => image_64
image replaced by image_1920 (when writing) or by image_1024 (when displaying
what was previously the big size)
+ add new intermediate format:
image_512
PR: #34925
Julien Castiaux