Suppose that a Task is added on a task via a studio customisation.
Then the _get_message_needaction method gets called on the onchange of the
toplevel task, which triggers another call to _get_message_needaction.
During that update, we get a self with a model.newID; its ids field is empty,
so the list of tasks res itself is empty.
As a result the method crashes on a malformed query.
This can in turn prevent the completion of some higher-level operation,
e.g. a state change on the task.
opw 1909043
closesodoo/odoo#29084
After a refactoring for v11, the id of a newly created thread is not returned
anymore.
Therefore server actions weren't being executed on newly created records.
opw 1886383
closesodoo/odoo#27238
The 'help' of window action is often fiddled with, adding thing before,
after or arround it.
For example in CRM leads, we add at the beginning "Click to add a new
opportunity" with an arrow towards the button, and after if there is a
mail alias: "All email incoming to * will automatically create new...".
But for crm.lead, hr.expense, sale.order this would not take into
account that the fiddled "help" can be edited, so if we edit 2 times
help in studio or backend action editing, we would get:
Click to add a new opportunity
Click to add a new opportunity
Click to add a new opportunity
[Original help content]
All email incoming to * will automatically create new...
All email incoming to * will automatically create new...
All email incoming to * will automatically create new...
And see several "arrows" towards the button (in enterprise the
additional ones are on same color background).
With this commit we do what is done in "mail.thread" by default which is
not fiddling with the `help` if has been fiddled before (if it contains
"oe_view_nocontent_create" class).
note: this is the 11.0 version of #26912
opw-1877663
closes#26911
- When a tracked field is modified, a mail.message is created.
When create is called its tries to fill missing values with "default
values".
It first tries to find the default values in the context, which may
occurs.
For example, modifying a tracked field on a subtask will add a key
"default_parent_id" in the context, which is the parent_id of the project.task.
Create will try to use "default_parent_id" for the mail.message
parent_id field, which make the SQL Request invalid.
Following 50ab18176 an access token is added in the URL, but there may
not be an existing access token. If so this commit generate one.
opw-1877347
closes#26526
This commit fixes two issues:
- If a partner has multiple users and if any of these users is a
share user, then the access button on mail notifications is not displayed.
- If a project.task is either assigned or has its stage folded
the access button may not be displayed for certain users.
The users affected by this bug are the one who have their user's
partner is linked to multiple users with at least one flagged as a share user.
Recently a ref() has been converted into a direct xml id match. As this
does not return a recordset but an ID, the .id that follows is not
necessary anymore.
Odoo puts in cache all stored fields of a recordset when you access the
first stored field not already in cache. In this particular case, Odoo
will put in cache all stored fields of 'mail.followers', which is
unnecessary and time consuming, especially on models where user follows
plenty of records.
With thousands of followed records, using a read() when searching on
followers is around 2.5 times faster than using mapped().
Record rules based on followers are speed up the same way.
In case an email received contains XHTML, `fromstring` fails because of
the following error:
> Unicode strings with encoding declaration are not supported. Please
> use bytes input or XML fragments without declaration.
opw-1832683
When parsing an email with some eml or dmg attachment, the parsing would
generate an attachment with empty content.
Since this content is later encoded in base64, it would crash trying to encode
None.
We simply do not process attachments without content.
We add a test to check that parsing mail with some empty attachment doesn't
crash, since the crash implies that the mail gets stuck on server
and is never fully processed by Odoo.
opw 1814014
Currently when posting a message if the author has no email address an user
error is raised. Indeed as posting a message goes through the process of
creating notifications and sending emails an email address is required on
the user.
In saas 11.2 a _message_log shortcut has been added to log notes. This
method should have the same behavior when author has no email. Currently
there is a crash when trying to encode its email. After this commit an
exceptions is raised like classic post.
This commit is related to task ID 1823990 .
Currently when posting a message if the author has no email address an user
error is raised. Indeed as posting a message goes through the process of
creating notifications and sending emails an email address is required on
the user.
In saas 11.2 a _message_log shortcut has been added to log notes and in saas
11.3 a message_notify has been added to notify peopel of a custom content.
Those methods should have the same behavior when author has no email.
Currently there is a crash when trying to encode its email. After this commit
an exceptions is raised like classic post.
This commit is a manual forward-port of 3a978cc64e6b1d8aca7cfd5d4e319bcb302dd262 as well as an improvement
to fix the newly-introduced message_notify method.
Cache invalidation when subscribing people has been added at e6f038a821.
Indeed subscribing partners to a record may lead to an access right update
as some of them are based on followers. This is why a cache invalidation
is necessary to avoid access rights issues.
However subscribing people to a record should change their rights only on
the records involved in the subscription mechanism. We can therefore give
ids to the cache invalidation to limit to updated records.
Cache invalidation is also limited when writing on followers if writing
on model, res_id or partner_id fields. Indeed changing subtypes or
channel of a subscription should have no impact on cache and access rights.
Cache invalidation done manually in _message_subscribe is not necessary
as subscription create or update mail.followers records since f9c210923d.
Create and write of mail.followers records already ask for cache invalidation.
It is therefore not necessary to invalidate cache twice.
This commit allows to save a few queries on some tests, notably about
activities that deal with subscription and messages. As cache is now kept
it is not necessary to refetch some data, leading to a few query gain. We
gain about 1K queries on com runbot.
A side effect of limiting cache invalidation is that some unit tests require
a manual cache invalidation to have up to date results. Indeed record not
being up to date in cache was hidden by the invalidation we just removed.
This commit refactors mail.thread message_auto_subscribe method. Purpose
of this method is to automatically subscribe people to documents in several
scenarios
* followers from an umbrella record to sub-records, like followers of project
added to tasks;
* responsible of documents, in addition to sending notifications to newly
added responsibles;
* some specific use case depending on some applications like managers
for expense reports;
New auto subscription now uses the recently introduced method optimized to
compute new or to-update followers. It is also rewritten so that overriding
it is easier. Indeed simply overriding _message_auto_subscribe_followers is
now sufficient to add new followers to a record, depending on some updated
values. It is also now possible to specify a template to use for some
specific notification, if requested.
Fetching auto-subscription data in subtype is also optimized. It is now done
in a single SQL query. All data related to parent (like project) and child
(like task) as well as default and internal-only data is prepared in a single
query and given back to auto subscription process. This allows to gain
queries in auto subscription based on subtype like project / task use case.
This commit has a great impact on performance counters. Complex use cases
involving tracking and responsible notifications gain about 30 queries which
is about 15% of their total query count.
This commit refactors mail.thread message_subscribe method. It is done for two
purposes. First one is to optimize performance by using the new followers
computation methods introduced recently. Second purpose is to clean the API
of message_subscribe to make it simpler to use.
This commit splits message_subscribe in two main parts :
* _message_subscribe is a private method calling the follower new
subscription methods and updating the record set;
* message_subscribe is a public wrapper on _message_subscribe that adds
access rights checks;
Simplification comes by removing message_subscribe_users that was a
shortcut to message_subscribe. Having a method to subscribe partners and
channels is sufficient as we would like to avoid bloating the public API
of mail.thread. A force parameter is also removed from message_subscribe
as this implementation detail can be induced in the computation.
Various addons using the removed methods are updated in order to use the new
subscription API. They have the same functional behavior.
This commit has a great impact when subscribing several followers. In a more
general way all code using message_post is also optimized as posting a message
generally implies subscribing followers. It also improves activity use as
posting a message and subscribing new followers are common process in
activities.
Override of create in mail.thread now uses the recently introduced
_add_default_followers to add the record's creator in the followers.
It allows to save one query when creating new records. It means for simple
models we approach the bottom limit in term of generated queries which is
quite a good news.
As explained in previous commit we can use xmlid_to_res_id instead of ref()
which leads to some query gain. We gain 1 query on most post due notably to
notify and logging is still improved. This leads to a gain of about 4K queries
on community runbot.
Use option recently introduced to use a minimal context when rendering
some mail templates such as
* notification template used to decorate messages sent to recipient
when using email-based notifications;
* user assignation template used when people are assigned on a record
and a notification is sent to inbox or email;
* message_post_with_template now uses minimal context meaning calls to
that method should be sure evaluation context is correctly set in
the given values;
This optimization allows to save some queries every time one of those
template is used, meaning all tests gain between 1 to 4 queries depending
on their complexity.
This commit is related to task ID 1817951. Closes#23291 .
Currently mail/view controller supports either a message_id, either a
model/res_id . Using a message_id is just a shortcut to find its model and
res_id before redirecting to the record view. If the message has been
removed the controller does not work anymore although with model and
res_id it still works while the record exists.
Same functional behavior can be achieved with only model and res_id. Let
us drop support of message_id to lessen code size.
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.
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.
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.
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.
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.
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.
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.
Christophe Simonis