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.
Before this commit, on a clear session, there was a traceback
after focusing out the emoji button next to the composer.
This is due to a DOM element that exists only after clicking on
the emoji button, and it was wrongly assumed that focusout cannot
occur without a preceding click. Indeed, we can press TAB to move
between focusable elements, so that we can have the focus in/out
on the button without clicking on it.
Before this commit, when the partner mention propositions dropup was visible
on discuss composer, pressing on TAB result in selecting the next focusable DOM
element after the composer input, which is usually the 'Send' or 'Log' button.
This behaviour is confusing, because users expect that TAB either autofill the
input or cycle through the propositions.
We decided to align on Slack's behaviour of TAB, which is to cycle through
the mention popositions from top to bottom.
Before this commit, when mentioning a user at the end of a message,
no link was shown.
The cause is that any mention should end with whitespace, but during
the preprocessing of a message, the message is trimmed, which removes
the final whitespace of the mention.
We would like to keep trimming at the preprocessing of the message,
but we can relax a bit the regex to detect a mention, so that it is
not necessary to have a whitespace at the end of a matched mention.
test_utils.js contains helper functions, which should be stateless
(good practices). This was not the case with patchWindowGetSelection
and unpatchWindowGetSelection, so instead we keep only the first
function which returns the second one.
From the test POV, instead of this:
utils.patchWindowGetSelection();
// ...
utils.unpatchWindowGetSelection();
It now looks like that:
var unpatchWindowGetSelection = utils.patchWindowGetSelection();
// ...
unpatchWindowGetSelection();
When sending notification from the frontend, if a template is rendered
for it and the user has the group "website.group_website_publisher" he
will get inherit_branding adding on elements things like:
data-oe-id="42" data-oe-model="ir.ui.view" data-oe-field="arch"
but the chatter system has feature automatically redirecting an element
that have attribute "data-oe-id": this caused for example that a
link notification towards the forum would instead be redirecting to
editing the view of the notification.
This fix distinguish the inherit_branding in the chatter feature and
ignore them.
opw-813333
closes#23225
If the activity had no summary the messages has a : leading to nothing
which is not very nice. If there is no summary, only display the "done
by" message followed directly by the feedback.
- 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
Currently if get_formview_id does not return a specific view id the
mail/view controller produces an url with view_id=False. Due to some
unknown reason it is not taken into account as False but as the
string False since some time. It generates a traceback and prevent
people from using the mail/view controller.
While finding why it seems to have changed we can avoid the issue by
setting the view_id only if set. It has no impact on the redirection
has the default for view is loaded as intended.
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.
This commit adds a new QWeb layout mail_notification_light. It is a new
lighter template using more modern styling. Its purpose is to be used as
a basis for all future templates used in notification mechanism (chatter,
sale orders, ...). During some time all templates will exist separately.
Future commits will gradually improve or add various notification
mechanisms. This new template will gradually be used more often in order
to replace old ones.
Thanks to @est-odoo for its in-depth testing of the template.
Revision on recent JS refactoring: https://github.com/odoo/odoo/commit/02ec09cb1c3e2d7bc7968f40c18f2208d7f3f498
Intermediary changes have not been updated with final way of communicating
with JS services. In particular, widgets must now explicitly call the
service with this.call instead of relying on a mixin that hides the service call
(e.g. the chat_mixin that has been removed)
Rev. on this commit: https://github.com/odoo/odoo/commit/02ec09cb1c3e2d7bc7968f40c18f2208d7f3f498
A consequence of the above commit is that @ mention were broken:
the dropup menu with partner propositions was not displaying when
the user typed the first characters to mention a user (e.g. by typing
"[at]demo" in order to show the proposed mention "[at]Demo User" in a dropup
menu).
This commit fixes the issue by reverting the logic of how mentions are provided
by the chat_manager, while removing some dead code.
note: [at] = @
Before this commit, if we wanted to add channels on rpc initMessaging,
we had to mock this rpc completely.
Now, with this commit, we can use data 'initMessaging', whose keys
can overwrite the default mocked initMessaging.
For instance, if this.data.initMessaging has the key 'channel_slots',
then the mocked initMessaging rpc will return a new state for the
existing channels to the chat_manager.
This is needed in order to reduce the size of tests than need some custom
initMessaging state, such as any test that needs at least one non-static
channel (i.e. neither channel_inbox nor channel_starred).
Before this commit, phantomjs was crashing when some code manipulates
window.getSelection (such as the composer input in discuss or in the chatter).
This commit lets us mock window.getSelection in tests that need this function
in order to work properly.
Another benefit of this commit is the possibility to simulate the state of
window.getSelection in our tests, which enables tests on the composer that
were not possible before (e.g. making sure that mentions and emojis are
correctly rendered in the input, after the user clicked on them in the dropup
menu or the bottom bar.
This commit adds a first test of discuss, which checks that the
essential DOM elements are present when we create a discuss widget.
In particular, there should be a sidebar that contains links to
channel_inbox and channel_starred.
In order to test discuss, the service 'chat_manager' has to be ready.
We do not want to explicitly write discuss.call on any test with discuss,
so now the function createDiscuss returns a promise that is resolved with
the discuss widget when the chat_manager is ready.
Discuss has to perform a rpc to fetch messages of its channels.
Some tests do not care of the result of this rpc call, so we mock
it by default (by default, channels have no messages in our tests).
In chatter, also linkify URL with IP address as domain name like it may
be in other part of Odoo (eg. plaintext mail received).
With this change, an URL:
http://192.168.0.1:8069/web
would be linkified.
opw-816175
closes#23153
The settings of a channel were available in debug mode only. Adding a settings button on each channel allows to read/edit a channel settings easily.
Remove the unsubribe button and the settings button from the top of the page since they can be acceses another way now.
* account, board, hr_holidays, mail, sale, website_sale
Small fixes on nocontent onboarding screens.
Initial commit: https://github.com/odoo/odoo/commit/a87d761fdbf345ada5dc93e0a686b08a0f5a0417
Details:
- list: centered;
- pivot/graph: centered + empty folder face;
- Dashboard app with nocontent helper;
- Discuss inbox/starred: centered without neutral/smiling faces;
=> no faces because it's too much with animated
rainbow man when emptying the any of the boxes.
- hr_holidays: fixed onboarding screens;
- (technical) dropped obsolete 'o_view_nocontent_container' style;
- manual reconciliation 'nothing to reconcile': centered + inside form sheet;
=> renamed account's o_view_nocontent to o_view_noreconciliation,
so that it doesn't use the style of views.less.
- kanban: nocontent helper above the columns (if any);
- texts "no order to upsell"/"abandonned cart" paragraph split in two.
Thibault Delavallée