Send methods of mail.mail model are set private and simplified. Those
methods have been written when a lot of overrides were necessary to
generate notification emails. Since then the flow has changed but
methods have not been updated completely. This commit therefore simplified
a bit the call chain and parameters.
This commit is purely technical and does not hold any functional change.
Purpose is to clean code in order to prepare future changes in mail
application.
This commit renames some internal mail.thread methods linked to the
notification process. This is the next commit of a series aiming at
improving code readability and method finding through prefixes. See
notably cae1c3977f, cdfe479e2e and fc1348dd3d.
This commit does not change any functional feature. It does only
rename notification-related methods, using the _notify prefix to
ensure they are private and to mark they are part of the notification
process.
Commit 0d3d0e9563 added a key in context when sending emails to know
the target model name. It was used at that time to forge for footer of
notification emails.
Since that time notification emails have evolved a lot. The code based on
that context key has been removed. Context key has been transformed into a
context switch. However it is not used anymore and can be removed. It allows
to clean a bit the code and save a context switch.
This commit is purely technical and does not hold any functional change.
Purpose is to clean code in order to prepare future changes in mail
application.
This commit allows to gain some queries in mail sending process, meaning
removing context switch is interesting. One query is gained when using
the send process. Complex performance test involving several message post
gain 3 queries each.
1d57a09112 added a two-steps parent fetch when posting a message
on a discussion thread. At the time this commit was done responsible were
notified of the first thread message. It was helpful to notify them of the
original email that created the thread instead of the "document created"
generic message. Indeed for documents like leads or issues having the
original email containing the customer question is interesting when being
notified. This is why this commit was done.
However since quite a long time responsible notifications have changed.
They now receive an email notification telling they have been assigned on
a document. This commit is not necessary anymore and we therefore remove
it in order to clean a bit the message_post process.
This commit globally reverts 1d57a09112. Please note that @beledouxdenis
agreed after a long thinking.
This commit has a slight impact on mail performance tests, allowing to save
one query in some more complex test case.
Purpose of this commit is to simplify a bit message_post API. It has
a content_subtype parameter allowing to receive plaintext content.
It is then automatically converted into html.
This commit removes the parameter and consider the content is always
html. Code calling message_post should handle the conversion. In Odoo
the only use was in the chat_post controller that now perform the
plaintext to html conversion before calling message_post.
This commit is purely technical and does not hold any functional change.
Purpose is to clean code in order to prepare future changes in mail
application.
Posting on users is not supported anymore. It was implemented in a time
we thought having a twitter-like behavior in Odoo was a good idea.
Posting on users was redirected on its related partner in mail. It was
redirected on its related employee in hr. It does not make sense anymore
as employee are records with limited access and partners used for other
purpose than discussing notably in accounting.
Now that we have chat channels it makes no sense to have this kind of
behavior still implemented. Let us remove it. No functional change
should occur with this commit.
Propagation was not correctly done at 8a026e26c6 . This commit
ensures all parameters are passed to sub-calls when redirection is done
in message_post.
* crm, hr_expense, mail
The nocontent helper can be generated either statically (in xml)
or dynamically (in python).
Before this commit, the result of some nocontent helpers was simply
the concatenation of the static and dynamic parts.
Due to recent changes (see https://github.com/odoo/odoo/commit/a87d761fdbf345ada5dc93e0a686b08a0f5a0417),
the nocontent helper has changed so that any of the nocontent helper
parts has to define its style for showing the face (e.g. smiling,
neutral, or folder face).
As a consequence of the changes above, the styles of some
nocontent helper screens were duplicated, e.g. two smiling faces
were shown instead of a single one.
With this commit, most dynamically generated nocontent helpers keep
only the dynamic part, so the static part is usually dropped in this
case.
Exception to above rule:
dyn_help = 'You could also add a new [document_name] by sending an email to [email_link]'
The dynamic part is appended right after the static help message, in its dedicated paragraph.
- Create a custom field
Field Type: monetary
Tracking: Always
- Install any module
A crash occurs in `_instanciate_attrs` since `attrs` is `None`.
In some special cases, the instanciation of the attrs of a field is
delayed at the very end of the setup. For example, in case of a Many2one
for which the comodel is not yet loaded.
Therefore the override of the method should take this case into account.
Closes#22922
opw-815185
A new notif_layout parameter has been introduced at 304e6cf90b. However it is
not correctly propagated to sub-calls when redirecting message_post
using context and sub-model.
Notification template has been converted into QWeb at commit 0f301bec25.
A variable renaming has not been correctly propagated, leading to
tracking values not being displayed in notification emails. This
commit fixes that.
When X is adding Y in a discuss channel, the recieved notification was:
- if read in discuss: from Y, "joined the channel" (no information who added him)
- if read in email: from X, "joined the channel" (misleading, think X was the
one joining the channel)
The problem comes from the author_id in the first case and the email_from in the
second, both containing a different value.
Also correct a bad api.multi parameter
Current behavior when assigning someone as responsible of a document is
to send him an email if he works using emails. Technically it is done
when writing on user_id field and based on notification_type field value
of the user.
This commit changes that behavior to push a notification to the new
responsible. It uses the recently-introduced message_notify method
allowing to push notification to recipients without being linked to
a document. It means people working in Odoo receive a message in their
Inbox while people working by email receive an email.
Assignation message contains a link to the document meaning it is always
possible to go to the document. Notification email uses the new template
defined recently. It allow to have a notification email a bit classy.
This commit implies that more notifications are created. Indeed previously
to this commit no notification were created for partners without user
or for users working in Odoo. There is therefore a performance test whose
counter increases and a slight increase in query count when installing
all modules, about 1K queries on 581K.
Mail API contains a message_post method allowing to post a message on a
document. In some cases we would like to push notifications to recipients
that are not necessarily linked to a document. For that purpose we
introduce message_notify. It is a shortcut that prepares the message and
speeds up the computation by pre-computing message values. This method
calls message_post and therefore the whole notification process. It
means no custom code for pushing inbox or email notifications is necessary.
Purpose of this commit is to allow to give additional values when rendering
notification emails and to make some parameters explicit.
This commit updates the _notify API. It allow to propagate a dictionary
containing values given to the rendering of the notification template.
This allow to have more complex templates and/or to control the rendering
depending on some parameters. Indeed currently only some fixed values and
values coming form the message to notify are given to the rendering
context.
First use will be soon when pushing notification emails not necessarily
linked to documents. In this process some values will be given by the caller
and not only by the message context anymore.
This commit also moves some context key used to control the notification
process directly in values given to the _notify method. It allows to make
those parameters explicit and rely less on context.
The _notify method now takes a values dictionary that may contain
* add_sign: add user signature to notification email, default is True.
It replaces the ``mail_notify_user_signature`` context key;
* mail_auto_delete: auto delete send emails, default is True. It
replaces the ``mail_auto_delete`` context key;
* other values are given to the context used to render the notification
template, allowing customization.
It allows to remove some context switch notably in the composer. A values
dictionary is computed and given to message_post and then propagated to
the notification mechanism.
Purpose is to allow to add parameters to the view link. Currently it is
formatted like '/mail/view?model=model&res_id=res_id'. We would like to
be able to add parameters like access token for example. It will allow
to create view links specifically tailored for some people like customer
portal.
Rev 666b594842 introduced an autodetection
mechanism for transforming base64 embedded images inside emails into
attachment with a Content-ID URL.
The patch suffered from several issues:
- the base64 detection regex failed to detect base64 data that is folded
over multiple lines - which happens to be the default in many Python
versions when a binary field is read, or when using the base64 codec
to encode a string.
(Those cases where left untouched and the image was therefore missing)
- there was a logic error in the code when the same image was present
multiple times, leading to an exception (`name` variable was
referenced before being assigned)
This patch addresses both issues.
Fixes OPW-815073
Since commit a18bd499ac alias_domain was
not updating correctly in the settings.
This commit fixes the issue by updating to code to conform to the new
config_parameter interface.
Since notification emails are not mail templates anymore they do not go
through the mail_template.render_post_process() method that converts
local links to absolute links. This means that buttons and images were
not correctly displayed in notification emails. Indeed those still had
local links.
This commit fixes that by moving the method directly in mail.thread and
calling it accordingly when rendering the notification email. Note that
the method has been changed in order to use regex instead of html
parser. It is done based on work already done in mass mailing application.
Indeed using parsers is complex and time consuming and may create
changes in the html structure that are not intended.
Next step in master is to go through various link modifications in
mass mailing module to see how to handle them properly. Maybe.
Notification emails now use QWeb to be rendered instead of jinja-based
mail.template since 2f7593761c. Part of the notification emails was not working
anymore since its syntax was still using jinja. This commit fixes that.
This commit also removes strange ';' that should not be part of python code
as well as an unnecessary variable propagation.
Activity mixin adds an activity_date_deadline field that is a related on
activity_ids. This one is a o2m using a domain based on the current record
model. Indeed activities are cross-model, like mail.message.
However as it is stored it generates are a lot of unnecessary computation
when activities are updated. Indeed when activities change the related
computation is triggered for every model inheriting from the activity
mixin. It then applies the domain in order to find record to update. This
generates a lot of void queries because only one will match the activity
model.
This commit makes the field not stored anymore. Indeed it is used mainly
in filters. Same functional result can be achieved using a computed and
searchable field.
We gain a lot of queries when creating activities as indicated by the
counter update in this commit. Creating a record inheriting from activity
mixin is a bit improved since there is less computed field to compute.
Creating an activity costs a lot less queries and we gain about 40%
in term of query required to create an activity when a lot of models are
using the mixin.
On community runbot it makes a gain of 2% when installing all modules.
This commit allows to save 13K queries on 587K (current) which is quite
good.
The access_token is automatically added by the media editor. It's added
on the website and by the html editor to send by email. The widget display
the attachments from 'ir.ui.view' (public attachment) and the attachment
from the current record.
Issue: can't load image in gmail or mobile because the client mail use a
proxy who avoid ours odoo access.
This commit improves the JS code of the mail module,
which comes maily from the new coding guidelines
and the addition of "JS services".
JS services are important objects that do not fit
well in the component tree, such as chat_manager
or ajax.
The benefits of JS services are improved readability
of the code, reduced coupling, and more testable
modules. In particular, discuss was hard to
Summary of the changes:
- ClientAction has been renamed into Discuss
- Clear instantiation of chatManager
- New coding guidelines in most mail modules
- JS Services can interact with each other
- Chat Manager and Window Manager are services
- Window Manager renamed to Chat Window Manager
- bus.bus is now encapsulated in Bus Service (a service)
- The test infrastructure has been tweaked with JS Services
- Chat Mixin has been removed
A future improvement would be to translate some 'trigger' into 'trigger_up'.
Before this commit, all the mailto:xx@ww.com in emails were transformed into
http://web.base.url/xx@ww.com
This was due to the url parsing of werkzeug urls.py, which definitely get the scheme
(mailto), but doesn't get the netloc of the url -- because it has no //
Ater this commit, we transform links to local ones, except if the scheme is mailto,
and the issue disappears.
OPW 807795
This message is not linked to any real subtype and will never be notified
to someone. It creates a notification with subtype note. It is however
different from user-created notes and should not be propagated.
Tracking triggering subtypes are managed differently as they have a
business related meaning. It makes sense to notify them to followers.
This message is not linked to any real subtype and will never be notified
to someone. It creates a notification with subtype note. It is however
different from user-created notes and should not be propagated.
New record creation suck as new task or new ticket are linked to subtypes
people can follow and defined in their own module.
This commit introduces _message_log to use when logging notification-based
notes on a document. Its main purpose is to provide a shortcut to the
complex mechanism of message_post. As it is a lighter code and as it
performs less checks and value computation it allows to clearly gain
queries when logging notes.
It does
* skip the notification process completely. Side effect is that followers
following note subtype are not notified of document created and pure
note tracking. This is considered more as a fix than a feature change.
Indeed following notes means that followers want to receive notes
logged by other users. The fact that system notifications without a
specific subtypes are also notes is a side-effect of the current
implementation;
* support only notification-based notes and should not be used currently
when logging real notes as those could trigger the notification
process;
* skip access rights checks as it creates the message as superuser. It
is therefore defined as a private method and should be called within
a method where access rights are already granted;
On community runbot installing all 203 modules takes 580K queries instead
of 690 at the time of testing. It is a 15% performance increase based on
the 'all modules installation' metric.
In a distant future message_post and message_log could be merged after
some cleaning but it is easier currently to have this shortcut available.
Moreover as there are clouds on the mail module some developers prefer
to already have some optimization and code cleaning done to avoid
loosing all their hair.
This commit includes a small test. In a same distant future more tests
will probably be added depending on how mail API evolves.
Only messages as comments and email template should keep a white backround since they are not internal.
It is also enough to display fields that changed on subtypes (update message) since emails will be reworked soon and more information will be given there. The support of 'always' track can be removed. (is now considered as a simple tracked field)
The use of self.env.ref('mail.mt_comment').id add some query and the performance tests needs to be update since message_format is called by notify_by_chat. This code will be refactor later
Thibault Delavallée