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>
Currently there is no way of knowing who changed the address
of a partner. This field is of high importance and should be
tracked to be able to follow who is editing it.
As addresses are represented with a bunch of fields, tracking
them individually would result in weird-looking tracking
messages with each value stacked on top of the other.
To avoid this, we take advantage of the fact that tracking can
be used on non-stored compute fields to log any change as a
change over the full address.
The full address is derived from the contact_address field to
take advantage of the existing regional formatting of addresses.
It is however modified to replace return to lines with commas to
accomodate the formatting of tracking messages in the front-end.
task-3165293
closesodoo/odoo#114695
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Use case
--------
If the a user has partner_share set to NULL not to 'false'
he will not receive any notification
The orm consider False and NULL value as False for boolean field,
the query that fetch the recipient data should have a consistent
behavior
closesodoo/odoo#117083
X-original-commit: a50fbd1f9404fd05eb576474eb3d10c94d37aa52
Signed-off-by: Thibault Francois <tfr@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
`PartnerRoot` is a confusing name for what is in fact what everyone call `odoobot`
closesodoo/odoo#116823
Signed-off-by: Debondt Didier (did) <did@odoo.com>
Steps to reproduce:
- Install l10n_mx modules
- Switch to MX company
- Create invoice and confirm it
- Send it to PAC in test environment (Process Now button)
- Click Send & Print button
Issue:
- XML Preview does not display, only shows the file name in the top right corner of the chatter.
Cause:
In l10n_mx_edi, when posting the invoice, the only attachment available is the xml sent to the government in `_message_set_main_attachment_id`.
Therefore the xml is set as the main attachment.
When clicking on "Send and Print", the pdf is generated but the main attachment is still the xml
Solution:
Redefine the main attachment everytime the the main attachment is an xml
Note:
- octet-stream have also been filtered out
opw-3085934
closesodoo/odoo#116784
X-original-commit: 48e6e81a47f5371f5985d135e56f39f445eb2854
Related: odoo/enterprise#38861
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#116167
Related: odoo/enterprise#38542
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Since [1], the `temporary_id` of a message is passed to the
`message_post` route in order to renconciliate the temporary
message on the client side and the real message created by the
server.
This led to crashes when sending message on the chatter because
this parameter was not allowed as a `_notify_thread` parameter.
Since this parameter is highly specific and isn't linked to any
business/model code, this parameter is now passed via the context
thus solving this issue.
[1]: https://github.com/odoo/odoo/pull/116085closesodoo/odoo#116333
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit removes the "new message" separator when posting a
message on a channel.
At the same time, this commit solves an issue that caused messages
to flicker when the message came from the bus before the answer of
the rpc.
In order to do so:
- messages are marked as read immediately after
`message_post` for the member of user that posted it.
- a temporary id is passed to `message_post` in order
to reconcialiate temporary/server messages.
task-3232911
closesodoo/odoo#116085
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Previously:
The displaying of the technical menu email would be cut
if you had a zoom of > than 100% on your browser
Currently:
It allows to see the whole content of the message without scrolling.
closesodoo/odoo#116124
X-original-commit: 5055b374c3bac0126f441dad61afd7e0b68b1370
Signed-off-by: Dalcq Jordan (joda) <joda@odoo.com>
OSError: cannot read from timed out object while evaluating a
"model._fetch_mails()", it occurs because when we try to quit a POP server
of incoming mail using the "pop_server.quit()" method, sometimes it is not
able to reach the remote server to quit the pop server, so it throws an OSError.
We added the try block for POP and IMAP.
if it fails then we display the os error.
sentry-3932133536
closesodoo/odoo#116004
X-original-commit: 0c30529cc9256c0b2483c2fcbbc599b87c1f8577
Signed-off-by: Anh Thao PHAM <pta@odoo.com>
Add back the 'sudo()' on batch mail unlinking.
Sudo is necessary to delete user notifications on auto-delete.
Which makes sense as the recipient would have an email for it anyway.
The sudo was there as far back as:
c5c369355d
Then transfered in this change:
036a739b62
And removed in the recent optimization here:
e38bfd25df1bb25e7e5695b536052d5a0c85c5c4
task-3225207
closesodoo/odoo#115956
X-original-commit: 93a28f17024511e30d3c70eb847c361ca87e0ffe
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Thiry Renaud (reth) <reth@odoo.com>
In mail, changing the setting "Restrict mail templates edition and
QWEB placeholders usage" to false should remove all users but admins
from the group, including the template user.
Before this commit, you could have weird behaviou such as
1. Disable the restrictiong (group_mail_template_editor in
group_user.implied_ids)
2. Install mass_mailing (group_mail_template_editor in
group_mass_mailing_user.implied_ids)
3. Create a user test with minimum employee roles (still has
group_mail_template_editor as employee)
4. Check the box "Restrict mail templates edition and QWEB
placeholders usage"
-> test still has the template group nothing implied it
The issue was a combinaison of recomputation of implied groups
https://github.com/odoo/odoo/blob/b2f760cae74201d1622e56a0027dae67dcff9e33/odoo/addons/base/models/res_users.py#L1292-L1295
that triggered the synchronisation of groups on template user
https://github.com/odoo/odoo/blob/b2f760cae74201d1622e56a0027dae67dcff9e33/odoo/addons/base/models/res_users.py#L611-L616
By removing the users already in a group, we avoid falling into the
condition added at 121cd0d608 where the default user gets a
group removed, readded, hence added for everybody.
closesodoo/odoo#115108
X-original-commit: 6398dd287f07641c85807f291d9fe078fcb8a231
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce:
- select a different company from the main one
- under settings/discuss enable External Email Servers
- set up an alias domain
- create an SO and send it by email
(you can catch the sent email using mailhog)
- reply to that email
(you can use the support-tools[1] and set In-Reply-To: "previous message_id")
Bug:
the reply_to field of incoming message defaults to the first company
Fix:
set the reply_to field to the company asociated to the record
(there's already a fallback to self.env.company in
"_notify_get_reply_to_formatted_email")
opw-3060214
[1]: https://github.com/odoo/support-tools/tree/master/scripts/mailclosesodoo/odoo#115090
X-original-commit: d86e57404d540762fa51afeabeddd3a0fc45d4d5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Purpose
=======
Currently the on_delete='restrict' implicit constraint prevents
the user deletion in case it's linked to a mail.activity record.
Set the on_delete attribute to 'cascade' as the record is not
of any usage without the user anyway.
Taskid: 3222941
Part-of: odoo/odoo#114656
This commit adds a check to prevent saving a translation in a language that was not installed.
Upon adding a translation, the field "language" in the request was not checker,
allowing to add translation for language (or any strings as key) for a given field
This is not ideal and we want to prevent that, it can bloat the database for no reason.
opw-3208305
closesodoo/odoo#114793
X-original-commit: 89cd5ce88a0c666e811410e264e3cb474f9851c0
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
RATIONALE
Naming conventions
* content = core message / subject (+ other fields);
* email layout = layouting applied to messages when sent to recipients who
receive notifications by email e.g. access button, ...;
* comment mode / mailing mode: composer main composition mode: posting on
record(s) / sending a mailing on records;
Content situation when using a template to post on a composer
* comment, monorecord mode: choose a template, content is rendered directly
from template side according to 'lang' field definition -> ok;
* comment, multirecord mode / mailing mode: choose a template, content is
the raw content. At post / send, content is rendered and translated if
matching template content -> ok;
Email layout situation when posting / mailing
* comment: layout translated based on template 'lang' field definition
or fallback on current user's lang;
* mailing: no layout supported;
PURPOSE
Translate layout into recipient's lang when available, instead of either
current user or template defined lang. As it is contextual better translate
it to the end user lang.
SPECIFICATIONS
Move recipients and email layout rendering into a method returning an iterator.
That way a list of recipient groups (as given by '_notify_get_recipients') can
be split into sub-groups, with each having its own rendering values for
email notifications.
Do a split / recipient lang. It is already fetched when notifying messages
as part of '_get_recipient_data' returned values. We now return recipients
groups per lang and per usage type (user, portal, customer, ...). Rendering
values are computed for each group as several values depend on the lang (
actions, notification buttons, global layout, ...).
Layouts when posting are dependent on recipient lang, and not on current user
anymore. Template lang that forced the content lang is now used only as a
fallback when recipient have no lang.
SUMMARY
When a user in Spanish, posts using a template specifying the lang of the
customer on a record whose customer is in French, with a follower being
in English
* content will be translated following template choice, aka french;
* layouting for the french customer will be in french, layouting for the
english customer is in english, while the core content is always the
same and in french;
When a user in Spanish, posts some custome content on a record whose customer
is in French, with a follower being in English
* content is whatever the user wrote;
* layouting for the french customer will be in french, layouting for the
english customer is in english, while the core content is always the
same and in french;
Task-3046371 (Mail: Better Language Support in Composer)
Task-2555155 (Mail: Translate notification action/access buttons)
Task-3186426 (Mail: Support notification layout in template / email composer)
Part-of: odoo/odoo#106177
Co-authored-by: Julien Banken <jbn@odoo.com>
RATIONALE
Naming conventions
* content = core message / subject (+ other fields);
* email layout = layouting applied to messages when sent to recipients who
receive notifications by email e.g. access button, ...;
* comment mode / mailing mode: composer main composition mode: posting on
record(s) / sending a mailing on records;
Content situation when using a template to post on a composer
* comment, monorecord mode: choose a template, content is rendered directly
from template side according to 'lang' field definition -> ok;
* comment, multirecord mode / mailing mode: choose a template, content is
the raw content. At post / send, content is rendered and translated if
matching template content -> ok;
Email layout situation when posting / mailing
* comment, monorecord model, using a template from UX: layout is partly
translated based on template 'lang' field to match the content translation.
Part of the layout still uses the current user lang;
* other comment use cases: layout is translated based on current user lang;
* mailing mode: layout not supported;
PURPOSE
Correctly propagate lang from template in all situations whenever a template
is used, and translate all layout parts.
SPECIFICATIONS
When using the composer to post messages (either as comment or in batch) the
language coming from the template is not propagated until the notification
process.
A hack has been done to try to guess the language inside the notification
process, based on context keys at odoo/odoo@9e71d228ed. This was done to partly fix
the bug in stable.
Since odoo/odoo@3eb9680602 it is possible to propagate a lang from 'message_post' or
'message_notify' calls until the notification process. We can therefore call
the posting methods using the rendered lang (in both mono and multi record
modes) and remove that hack.
When a lang is propagated using the 'force_email_lang' it is used to choose
the language of the layout (content, buttons). Currently all recipients
receives the same language for layouting. We plan to soon use the recipient
language when possible, then fallback on that forced lang. This will offer
more granularity and a better user experience.
When using scheduled messages (creating message but delaying the sending of
notifications) it is also working as notification parameters are saved when
creating the scheduling record, see odoo/odoo@9b11a9d82b.
EXAMPLE
A user in english uses a template on a lead whose customer is in spanish
with a follower being in german. Template lang is customer's lang:
* content is translated into spanish (customer's lang);
* layout is translated into spanish (customer's lang);
Both recipients (customer and follower) receive the content in spanish.
LINKS
Task-3046371 (Mail: Better Language Support in Composer)
Task-2555155 (Mail: Translate notification action/access buttons)
Part-of: odoo/odoo#106177
RATIONALE
Naming conventions
* content = core message / subject (+ other fields);
* email layout = layouting applied to messages when sent to recipients who
receive notifications by email e.g. access button, ...;
* comment mode / mailing mode: composer main composition mode: posting on
record(s) / sending a mailing on records;
Content situation when using a template on the composer
* comment, monorecord mode: choose a template, content is rendered directly
from template side according to 'lang' field definition -> ok;
* comment, multirecord mode / mailing mode: choose a template, content is
the raw content. At post / send, content is rendered on composer side.
As composer is not translated -> no translation -> ko;
PURPOSE
Take translations from template when composer content is the same as the
template one to benefits from their translations.
SPECIFICATIONS
When rendering some fields fetching translations can be complicated. Indeed
when using a template the translation is stored on template model while the
rendering is done on composer model. Translations are therefore not fetched
as fields of the composer record itself are not translated. It is a transient
record, not something people translate manually like templates.
As translations are not stored in a table anymore we can't really fetch
translations, except from using directly the template field. In this commit
we therefore do the rendering based on template value instead of composer
value when they are considered as equal and if a translation is asked either
through 'compute_lang' of 'force_lang'. This allows to fetch template
translations instead of composer translations.
If the composer content has been modified compared to the template we keep
the old behavior, which means probably no translations. Let us hope editor
does not mess too much with html content.
EXAMPLE
A user in english uses a template on a lead whose customer is in spanish
with a follower being in german. Template lang is customer's lang:
* content is translated into spanish (customer's lang);
Concerning layout (to be fixed in next commits):
* layout is partly translated into spanish (customer's lang) if coming from
form view, otherwise is in english (current user's lang);
LINKS
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#106177
When rendering content, options can be given to trigger some behavior
like post processing (links shortening) or comments to preserve in html
(for email reader specific commands).
In this commit we make an allowed list of options. This eases debugging
or finding wrong calls, outdated options, ...
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#106177
Purpose of this commit is to improve behavior or mail.compose.mixin when
removing the template. It now voids the value to avoid having half baked
definition on composers.
Summary of behavior
* when choosing a template: existing (non void) values override any value
in the composer mixin;
* when removing a template: reset values;
* when going from templateA to templateB: works like choosing a template
which means only non void values are taken. This may lead to half-baked
content but trying to remove old template content based on _origin and
content comparisons would be complicated for few added value;
This makes the 'mail.compose.mixin' behaves like 'mail.compose.message'
wizard which was recently updated at odoo/odoo#107356.
Task-3093257 (Mail: The Composer Update)
Part-of: odoo/odoo#106177
RATIONALE
Purpose of this commit is to add helper field knowing if body any model
inheriting from the 'mail.composer.mixin' is synchronized with their
template value.
SPECIFICATIONS
Add a field to check if body of a composer is the same as its template
* compare both current (raw) values and sanitized values, as sanitization
process may change some bits of html code;
* correctly check for void content using the tool;
Obviously this may be broken if editor usage changes the source template value
DOM when saving it in the composer. However we can't do much more than using
the original and sanitized values from template and compare them with the
current composer values.
It is used in this commit to simplify a bit code in '_render_field' override.
It is used to detect any change in body based on template. It highlights
potential changes in QWeb directives which requires usage of editor group.
This method is also cleaned in order to have less calls to super() in nested
if-elif structures. As some additional code will be added soon it is better
to have a simpler code flow.
Finally add some tests about current state of fields synchronization notably
when setting a template with void values, or removing the template.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#106177
Mail composer mixin already synchronizes subject and body based on a mail
template, easing calling rendering methods available through mail render
mixin.
In this commit we add the same mechanism on lang. Lang is taken from the
template and can be used to render content based on language defined on
template, generally based on a customer.
Some query counters are updated, without being sure those are really coming
from this commit. Anyway they will be updated in batch at the end of this
PR, as tracking them on each commit is tedious and not always really
useful.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#106177
This commit contains mainly code cleaning, docstrings and a small split
for notification tool methods. In this commit we
* make some notification groups variable explicit;
* move the filler of groups into its own submethod to ease being called
from other code (to be used soon);
* fix some strange overrides or code manipulation;
* propagate some additional parameters to ease future commits that will
improve rendering of groups-based notification emails;
* cleanup, fixup and improve docstrings;
This does not change anything from functional point of view, just preparing
further work.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#106177
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 contacting the server through the /websocket route, self.env.uid is
never set for the public user as we don't go through the
`_auth_method_public` method.
But through HTTP, it is set which is why guests were not subscribed to
their channels as their self.env.uid corresponded to the public user.
So we use request.session.uid instead, which remains unset for public
users.
closesodoo/odoo#114659
X-original-commit: 7059fdd2c8c36d6741d943ac2b61e971a4d05dcf
Signed-off-by: Denis Vermylen (dve) <dve@odoo.com>
When being notified on a document they cannot read users should be able to
post, as indicated in message ACLs. However some data preparation prevents
from doing it as ACLs are raised on document level.
In this commit we sudo the call to display_name to populate record_name when
not given. Indeed access is checked at message level so no need to crash in
this specific use case.
Task-3213982 (Mail: fix 'multi-company' post support)
X-original-commit: odoo/odoo@2d73c61136
Part-of: odoo/odoo#114511
When replying on a document they cannot read (notably when being notified)
ACLs raise when trying to check if 'main_attachment_id' is already set before
updating it. This is fixed in this commit. This fixes the recently introduced
'test_post_wo_access' test that does not pass without this fix.
Note that the update of 'main_attachment_id' was already done in sudo. As all
read or update access is now done in sudo, better call the whole method as
sudo in 'message_post' and let '_message_set_main_attachment_id' works on
the given record set environment.
Task-3213982 (Mail: fix 'multi-company' post support)
X-original-commit: odoo/odoo@0375bb227a
Part-of: odoo/odoo#114511
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
The attribute _mail_post_access='read' on a model allows user with read only
access on the model to post a message. It was not taken into account on the
client side, making the send message button disabled for user with readonly
access on such model. This commit fixes this issue and now correctly takes
into account that class parameter.
Task-3178885 (Mail: fix 'readonly' post support)
X-original-commit: odoo/odoo@d2b8612cf7
Part-of: odoo/odoo#114511
The attribute _mail_post_access='read' on a model class allows to post on that
model with readonly access. But when providing an attachment such action was
throwing a security error due to the check done on the attachment. Indeed
adding an attachment to a model is modifying that model so the write access
is needed. To solve this problem, we add the attachment in sudo in the
'_message_post_process_attachments' method.
Justification
This is an internal method and we have stated in its documentation that it is
the caller responsibility to check the rights. Actually, the checks are done at
mail.message creation (to which the attachment are linked) by the override
of 'check_access_rule' which calls '_get_mail_message_access' which takes into
account that attribute (_mail_post_access). Moreover sudo is already used
in '_message_post_process_attachments' to link existing attachments. Here we
add a sudo for the new attachments as well.
Note
This fix allows the test 'test_post_with_read_access' to pass (located in
test_mail/tests/test_mail_multi_company.py). But it is currently hard to
reproduce functionally as
- answering an email works as it is executed by the cron;
- replying in discuss trigger a multi company error no matter there is an
attachment or not (so it is another problem);
- sending a message (with readonly access) on a thread from the interface
works without this fix because the attachment are created beforehand and
the part that handle already existing attachment is already in sudo;
Multicompany issues will be solved in the next commits.
Task-3178885 (Mail: fix 'readonly' post support)
X-original-commit: odoo/odoo@f9a6f7f7ce
Part-of: odoo/odoo#114511
Due to misplaced / missing parenthesis some corner cases were not correctly
computed, notably when having Falsy values and using the fallback. Also
it was returning the thread ID instead of a boolean. This was not harmful
but better return a boolean "is a thread notification".
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#114511
RATIONALE
Currently email layout choice is done in code and is not controllable through
any user interface. In this commit we prepare improvements in template
management by allowing to choose the email layout directly from a given
mail template. As number of layouts is going to grow better be able to
choose the right one.
SPECIFICATIONS
Add a field on template to propagate email layout choice directly on
template and propagate it to the composer, then post/notify process.
We can now choose directly on a template which notification layout should be
used in conjunction with this template. Composer model already holds a field
'email_layout_xmlid', used in various places in code to give a specific
layout to use when sending notifications emails e.g. SO email layout. This
can now be specified directly from the template itself. It allows to
customize the look and feel of notifications without having to do it
explicitly in a given code flow.
Computation is coming either from template, either reset. When having a
template with a value set, set it on composer. When removing the template
reset it.
Currently no standard template uses it as this task targets mainly a code
cleaning that began with the composer code cleaning. It targets the near
freeze to have the base code updated once, then functional templates will
make use of it (hopefully).
Note that currently notification layout is still not supported at composer
level for mailings. It is simply ignored when generating outgoing mail
records. This will be improved soon.
Global followup of odoo/odoo#107356 / Task-2088884 (Mail: Use editable
computed stored fields in composer).
Prepares code for Task-3046371 (Mail: Better Language Support in Composer)
see odoo/odoo#106177 .
Task-3186426 (Mail: Support notification layout in template / email composer)
closesodoo/odoo#114462
Related: odoo/upgrade#4404
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
The bounce emails aren't stored in Odoo, which can complicate the
debugging of the email sending.
Now, we store this bounce email, and we allow the user to read it from
the interface, so he can easily find the issue when an email sending
fail.
Specifications
==============
The bounce email is stored on the mail notification for standard emails
sending, and on the mailing traces when using mass mailing.
For some email providers (e.g. Yahoo), the "Final-Recipient" header is
not present. Normally, it allows us to retrieve the original recipient
of the email which bounced and then the partner. So if this header is
not there in a bounce email, we take the first recipient of the parent
<mail.message>.
Change the way that we parse the email body, for the bounce email.
For most email providers, the first mail body is the one that contains
the error and the next one contains the parent email body. So, the
current logic might ignore this body for Outlook and Yahoo.
Task-2116296
closesodoo/odoo#105923
Related: odoo/enterprise#34051
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
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
This simplifies the use of subqueries by avoiding some costly default
order on the model or the idiotic order='id'. Method _flush_search()
has been adapted accordingly.
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
Some code cleanup done when moving the main attachment into its own mixin:
- improved docstring
- early returns
- code simplification
No functional changes should occur with this commit.
Task-2648976
Part-of: odoo/odoo#110734
Main attachment is quite costly and as it is implemented in mail.thread, is
present in most model. In order to improve performance, we remove it here from
mail.thread and add it, through a new mixin, only on models that actually use
that feature.
Technical note: with the current implementation, even if the font-end view
expect the model to implement the main attachment feature and the model
doesn't, it doesn't crash. Indeed, the main attachment on the front-end is only
used to know the first image to display in the image 'carousel' on the right
(widget rendered through the presence of the class o_attachment_preview). And
as 'register_as_main_attachment' of ir.attachment doesn't crash even if the
model doesn't support main attachment feature, the only consequence is that the
first image to display is not persisted (if you refresh after changing the main
attachment, it will get back to the previous one).
Task-2648976
Part-of: odoo/odoo#110734
Inactive users should not be added in followers of records, especially using
automated subscription. Indeed they mainly generate noise in notification
process and are generally skipped.
Few use case exists of inactive users creating records. One use case is the
mailgateway running as root but a context key 'mail_create_nosubscribe' is
used to avoid it. Other use cases include automated action for example who
are also generally protected.
Anyway better be sure and consider this is a standard use case. To extend
this rationale, inactive people are currently not added when posting. It
therefore makes sense to keep this behavior coherent through the mail stack.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#113522
This fixes the problem of the full res_partner form being displayed instead of
the simplified one in some cases (and vice-versa).
The problem can be reproduced by the following steps:
- launch odoo without xml dev_mode enabled (otherwise the cache is disabled)
- in helpdesk, go to an existing ticket and click on an existing customer (this
will load the full form for the customer into cache)
- create a new ticket by first completing name and customer name, save it
- complete the email address, save it
- go to "Send message" and click on the email checkbox
- the full form is loaded instead of the simplified one
(base.view_partner_simple_form)
It is also possible to get the simple form instead of the full form by
reversing the order of the visited forms.
Technical note: The problem has been fixed by adding the context key
"force_email" as cache key using _get_view_cache_key override. Indeed,
_get_view_cache uses _get_view which result depends on that context variable in
its redefinition in res_partner.
Task-3024050
Part-of: odoo/odoo#105111
Selecting a recipient for which there exists no partner trigger a partner form
dialog creation. For some model (ex.: crm.lead), some default values can be
prefilled from the current record. This is what we do here by calling a generic
mechanism that allows each model to define default value for related partner.
Note that we don't provide a more detailed form to the user because some will
otherwise feel obligated to fill it out entirely.
Technical note: As there is no need for a custom form per model from which the
data are extracted to populate the related partner, the simplified partner form
(view_partner_simple_form) is just augmented with additional invisible field by
modules that add fields to partner and need to populate them automatically from
values of another model.
Technical note: In TestCRMLead.test_message_recipient_partner_auto_creation, we
test that the _message_get_suggested_recipients returns the correct default
values to copy some fields from the lead to the partner to avoid the user to
reenter them. But we don't test specifically that it also work when using mail
composer and template (which generate the partner) because it has already been
tested when introducing the mechanism. Although, we verify that it should
behave the same because we verify that the default values returned by
_get_customer_information, that is used in mail template when using the
composer, are the same as the ones returned by _message_get_suggested_recipients
which is tested here.
Task-3024050
Part-of: odoo/odoo#105111
Sébastien Theys