Starting from this commit bounce addresses set in emails will not use any
plus addressing. They will always be ``bounce_alias#@alias_domain`` and
not ``bounce_alias+<mail_id>-<mail_model>-<mail_res_id>@alias_domain``.
Reasons are
* this plus addressing adds information we do not use anymore since a long
time as bounced messages are found using their message ID and not any
information coming from this bounce address;
* this generates unnecessary noise;
* not all email providers really support plus addressing as a mean to
generate "fake" additional email addresses;
This is the followup of odoo/odoo#71244 where a solution to avoid plus
addressing was done in table. We can now safely remove this feature in
master as a cleaning step.
Task ID-2577328
closesodoo/odoo#73363
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Remove the "email_send" field on the <mail.channel> (mass_mailing named
on the JS side).
This feature will be introduced with a new model (<mail.group>) in a
new module in the next commit.
Remove the email notification support on the channel, so now the mail
channels work only by chat.
Remove the "subject" on the Discuss side because this was used only on
"email" channel.
Technical
=========
In the mail channel model we can drop the usage of the blacklist as well
as the usage of the "email_to" field. Those two features were mainly
used for mailing list and have no utility for "chat like" channel.
Links
=====
Task-2510267
See odoo/odoo/pull/71599
See odoo/enterprise/pull/19296
See odoo/upgrade/pull/2600
Rationale
=========
Currently, mail channels have 2 modes
- They can be used like Discuss channel (chat, livechat, group)
- They can be used like a Mailing List (with the "email_send" field)
The mix of both feature in the same model causes some code complexity.
Several fields are not used in both cases (moderation related field)
and the future "Discord like" Discuss will even push the mail channel
further than the usage of the mailing list.
Because of all those reasons, we want to split the 2 mains features of
the mail channels into 2 different modules and models.
Purpose
=======
This commit remove the moderation feature of the mail channel
(email_send=True). This will be re-implemented in a separate module
in the next commit.
Do not be able to check messages in Discuss anymore because this
feature is only used to moderate the message and this feature will be
spitted in a new module "mail_group".
Links
=====
Task-2510267
See odoo/odoo/pull/71599
See odoo/enterprise/pull/19296
See odoo/upgrade/pull/2600
PURPOSE
In Odoo, there exists many different templates (contacts, spreadsheets,
etc.). To help the users distinguish them in the settings, we will rename
the menu item 'Template' to 'Email Template'.
SPECS
- Rename the menu item 'Template' to 'Email Templates'
LINKS
Task id: 2587224
closesodoo/odoo#73430
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This branch adds request.redirect on all requests.
In case of a front end request, we do an url_for to the location.
We removed redirect_with_hash that was only for retro compatibility
local_redirect has been renamed to redirect_query, and param keep_hash has been
removed and moved.
Default code for redirect is 303 now instead of 302.
Now redirect and redirect_query make local redirect by default, you need to
pass local=False to make external redirect.
All werkeug.utils.redirect has been replaced by request.redirect.
Http.redirect now use an http.Response type, and it become easy to add an
override like 'set_cookies' e.g.
Dispatch of a website.page return an http.response too, so we first need to
check if it is a cached version before to check if it is an Odoo Response.
Migrate your code:
http.redirect -> request.redirect(location, code, local)
http.local_redirect -> request.redirect_query(location, query, code, local)
http.redirect_with_hash -> request.redirect
Courtesy of odony for help and review ;)
closesodoo/odoo#72599
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
* google_recaptcha, mail, partner_autocomplete, point_of_sale, website
Now, to read session information, the module "@web/session" must be
imported. Not that, there is also the user service with all the user
information.
closesodoo/odoo#73201
Related: odoo/enterprise#19434
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Current bounce message is not very user friendly. Purpose of this commit
is to improve it, by improving wording and overall phrasing used in it.
Form view is improved so that bounce message takes all available width in
form view.
Some tests are added, notably to detect pseudo-void content from editor.
Task ID-2532529
PR odoo/odoo#71793
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
add resetLocalState method to rendererWrapper and test activity view is not
crashed on on_destroy_callback
task-2466057
closesodoo/odoo#73022
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Steps to reproduce:
- Install 'Accounting' module
- Switch to "My Company (Chicago)"
- Create an invoice
- Set Invoice date to 1/1/21 and
- Set Due date to 1/3/21
- Add any product and 'Confirm' invoice
- Go to customer profile
- Click on 'Due' stat button
- Click on 'Send by mail'
Issue
In received email, logo displayed is of "My Company (San Francisco)".
Cause
Env company not used.
Instead, logo of customer.company_id is used if mail type have
company_id field,
else will fallback on user.company_id
Also, if customer.company_id is null, it will fallback on '0':
/logo.png?company=%s' % (company.id or 0)
Solution
If mail record have NOT a company_id field or is not set,
set company to self.env.company.
Else, set company to record.company_id.
opw-2474114
closesodoo/odoo#73099
X-original-commit: 316b5956844d6f77f6fef1efeb5a8a8505e36e8e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, failure_reason was also copied when user duplicate email.
Which is not correct since the Mail is never sent not failed.
With this commit, failure_reason will not be copied when user duplicate email.
closesodoo/odoo#71690
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, activity view does not support many2one_avatar_user widget due to
which clicking on image do not open chat window, with this commit, we add
support of many2one_avatar_user widget in activity_view so that user can click
on avatar image and open chat window.
task-2554466
closesodoo/odoo#71804
Related: odoo/enterprise#18803
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
When sending a notification, the company used is:
- company_id of current record or if not available,
- company_id of author or if no author,
- company_id of user
This can seem unexpected if the author is the current user and the
company_id of our user is different than the current company switcher
company.
With this changeset: the company used is:
- company_id of current record or if not available,
- company_id of author if author is different than user or,
- current company in company switcher or if not,
- company_id of user
opw-2472622
closesodoo/odoo#73031
X-original-commit: 3f61d9e2dadf47d211ed078b36e9f3a416bbbff0
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit:
Currently, failure notifications are sent to the author of the message that the
failure is concerning.
However, if another user than the author is resolving the failure, he is not
receiving any notification without refresh the page, so it appears as if nothing
happened even though the failure was indeed resolved
(either message resent, or failure ignored).
After this commit:
When another user than the author update the status of the failure notification
(message resent or failure ignored). the statues of the failure notification
update instantly, no refresh needed to show the updated status.
Task-2178257
closesodoo/odoo#68860
Related: odoo/enterprise#18748
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* = hr, hr_holidays, im_livechat, sms, snailmail, website_livechat,
website_slides
Exporting directly on the line of the class or variable definition is less lines
of code and less repetition (and risk or mistake).
Exporting with a name instead of default allows to catch typos more easily when
importing and ensures the same name is used for consistency (and ease of grep).
closesodoo/odoo#72597
Related: odoo/enterprise#19224
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Clean up pass towards using bootstrap in template, not all hard-coded values are
converted yet but those have been done:
- `width/height: 100%` by `map-get($sizes, 100)`
- `margin/padding` with hard coded value with `map-get($spacers, X)`
- `border: 1px` by `$border-width`
- hard-coded black and white by `$black`/`$white`
- hard-coded `border-radius: 50%` by `@extend .rounded-circle;`
task-2223232
closesodoo/odoo#72321
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce :
- Install `CRM` and `Sales` modules
- Go to Settings, activate "External Email Servers" and
set an alias.
- Edit 'Sales Team Europe' : add an alias
(ensure alias end with the "External Email Servers" alias)
- Send a mail to the europe sale team alias email with a
base64 image in the html body
ex: <img alt="" src="data:image/png;base64,ABCDE123....789">
Issue :
- Traceback is raised.
("ValueError: Wrong value for ir.attachment.type: 'opportunity'.")
Cause :
Both `crm.lead` and `ir.attachment` have a `type` field.
When creating the thread, in this case of crm.lead model,
it will add the 'default_type' and 'default_team_id' to the
context.
The context will be inhrited and used on the creation of the
ir.attachment (in this case its the base64 encoded image
inside the body).
Since no `type` was provided while creating the ir.attachment,
it will set the type from `default_type` in context since
available.
Solution :
- Clean the context (in this case, it will remove `default_X` values)
when creating the ir.attachment .
opw-2551461
closesodoo/odoo#72613
X-original-commit: 4504c9d8069082c9542226fbafdbf309089cf7a9
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit the doAction method of the action_service did not support
to pass props directly to the Component. Only a few ad-hoc options were passed though.
After this commit, doAction can take a key "props" in options, that will be passed to the Component
(a View or a ClientAction)
the new API becomes
```ts
interface Options {
props: { [key: string]: any };
...
}
doAction(action: ActionRequest, options: Options);
Note that some props (like withFilters) are set by the action service
and cannot be set via the key "props".
Alongside the change mentioned above, we take the opportunity to align the
terminology used in action service to the one used server side: we know use
the terms resModel, resId, and resIds instead of model, recordId, and recordIds.
```
closesodoo/odoo#72397
Related: odoo/enterprise#19127
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
When a bounce has to be managed on a record already inheriting from blacklist
mixin it shoudl not be counted two times: one for email-based bounce and one
for "all records using that email linked to blacklist mechanism should
bounce".
A mechanism exists to prevent that double increase but it was not correctly
done. Protection was reset in a loop.
Task ID-2547347
PR odoo/odoo#72347closesodoo/odoo#72420
X-original-commit: 6e1bca5df19392d384d7c398b7aea66b62381938
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since odoo/odoo@f4524f03c3 plus addressing is not used anymore
for handling bounces. Indeed it relies on references / in reply to to find
original message that bounced. It is therefore not necessary to enforce the
use of plus addressing.
As some provider do not support plus addressing as a way to contact left-part
of email with sub-informations people should have a way to deactivate plus
addressing used in bounce aliases.
To preserve backwards compatibility for stable versions old behavior is
retained unless a new `mail.bounce.alias.static` ICP is set with a truthy
value.
Fix https://github.com/odoo/odoo/issues/71242 by dropping requirement of plus addressing.
@Tecnativa TT29827
Closes#71242
Task ID-2547347
PR odoo/odoo#72347
X-original-commit: df2d955bf41b01556e1b84bb1204aac045c95a63
Before this commit, suppose we have a scenario like below
Task-A:
Activity-1:
name: Email ( Today )
Assigned to: User-1
Task-B:
Activity-1:
name: Email ( Today )
assigned to: User-2
Activity-2:
name: Call ( Due in 3 Days )
assigned to: User-1
When User-1 goes through the systray 'Today' filter shortcut he gets both
Task-A and Task-B in the list instead of only Task-A. Indeed currently
activities are not filtered based on current user with its deadlines.
However purpose of systray is to indicate activities current user has to
perform instead of global activities.
After this commit activities will be filtered based on deadlines as well as the
current user. In order to achieve this behavior we needed to pass a domain like
[
('activity_ids.date_deadline','=', fields.Date.today()),
('activity_ids.user_id','=', 1)
]
And for that purpose we introduced a non-stored compute field with a search
method.
Task ID-2438822
COM PR odoo/odoo#72219
X-original-commit: f4eaf4d8fb2f97240201104dcd4fc7e2674bce02
The new execution environment of wowl tests has to take into account that legacy objects
can be spawned below it and around it, in particular in mail tests where mail has to create
an owl environment with the right keys.
This commit aims at making this work namely by being to pass an already formed legacyEnv
to the createWebClient helper
Overall colors review to achieve WACG standard compliance.
https://www.w3.org/WAI/standards-guidelines/wcag/
Current contextual colors work fine when used for backgrounds but fail
WACG tests when are used for text.
Unfortunately Bootstrap use the same palette in both scenarios without
providing effective control over text colors.
The 'text-emphasis-variant' mixin, indeed, allows to darken a color by a
certain amount, but since the amount is not customizable per-color the
final result is always either too dark or too light for colors that are
not used as a reference.
This commit will define a specif SCSS map called `$o-theme-text-colors`
that mirrors the default '$theme-colors' structure and contain
fine-tuned values to be used specifically for text.
In order to keep the same classes names, we customize the default
'text-emphasis-variant' mixin, instructing it to first look for our
fine-tuned colors and eventually fallback to default.
This commit will also adapt all the modules that use to hardcode text
colors in SCSS rather than using default utility classes. We handle this
using different approaches:
- Use utility classes whenever is possible (eg. 'text-info')
- If apply the class directly is not possible, '@extend' it in SCSS
- If '@extend' is not ideal because of code complexity (eg. ':hover'
interactions), use the new 'o-text-color([color name])' scss function.
This commit splits the 'getActionManagerTestConfig' helper into 2:
'setupWebClientServiceRegistry' and 'getActionManagerServerData'.
The first one is now automatically called by the 'createWebClient'
helper, as it properly setups the service registry with all services
required by the WebClient component.
The second one generates a few data (menus, actions, views...) that
can be used in tests. That helper is mainly useful for action tests
(formerly ActionManager tests) in web. With this refactoring, they
are no longer generated for each test in the whole codebase that
spawns a webclient, as before this commit.
closesodoo-dev/odoo#906
Related: odoo-dev/enterprise#161
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Drop custom 'bg-X-full' classes since we can now achieve the same visual
result using default 'bg-X' classes (it was not the case with prev.
bootstrap versions).
Ensure text readability for both 'bg-X-light' and 'btn-link' classes.
This commit adapts the community codebase to the rewriting of the
/web application in owl.
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
This commit adds some tests on mailing.activity to ensure read grouping is only
possible when the user has access to the underlying document.
Task-2272475
This commit adds some tests on mailing.activity to ensure _searching is only
possible when the user has access to the underlying document.
Query count for 'test_adv_activity_mixin' had to be slightly adapted (+1) since
calling 'action_close' in turn calls 'activity_search' that calls 'search' on
mail.activity that now runs an additional query (see '_search' override
docstring).
Task-2272475
Right now, for notifications handled by odoo (which are being displayed on
discuss app / object chatter), few of the buttons have unexpected scroll
(mostly the CTAs that redirect to record / portal views) and ruins the UI.
This commit fixes the issue by improving such templates by using proper
paddings on the button.
TaskId:2518863
closesodoo/odoo#70083
Related: odoo/enterprise#18225
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
It is currently escaped as it is not Markup-ed and not considered safe.
It means raw content is currently displayed in sent emails, which is not
really what we expect.
closesodoo/odoo#71911
X-original-commit: 62e6bc216aefe93c4cd1cca8e39f124a8a298386
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
HTML fields used to have a toggle button for a "code view" (which came
from the Summernote library), in debug mode. This allowed the advanced
user to edit content with jinja conditions. This was lost with the new
editor but reintroduced for Mass Mailing. As it turns out it was needed
elsewhere so this makes the code view available as a node option, and
already activates it for mail templates.
To activate the code view in an html field:
```xml
<field type="html" options="'codeview': True"/>
```
Task: 2561300
closes#71860closesodoo/odoo#71891
X-original-commit: 0f9684677676b563a0ff2712e42cea24a2ef27bb
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
We should not assume that the default date of the message is "now". A message
should only have a date when it's coming from the database that supply it.
closesodoo/odoo#70069
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit there were few cases in which
is_html_empty method was not working as our expectation.
In cases such as "<p class=""><br/></p>", "<p id=""><br/></p>"
and many other cases.
In this commit we improves regex of is_html_empty method.
Mow from this commit all kind of attributes will be consider
in this method.
In this commit we also have added is_html_empty in mail template, portal
values and in report values also for rendering templates.
Task id: 2499504
X-original-commit: fd0a05f2955b9f7e9ae7233afebfd6240c9244dd
- added test case for click on author name and on author avatar.
task-2391179
closesodoo/odoo#71746
X-original-commit: df2f110df0fb7cbfee55e611cb0ceee4aceefdcf
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The timestamp color should be gray instead of primary green even when the thread is unread or needs action.
Task id: 2383054
closesodoo/odoo#71034
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
PURPOSE
- A helper should be aligned vertically in the systray menu.
- A sentence should also be changed by
"Congratulations, you're done with your activities."
SPECIFICATION
A helper changed and also it will be appeared in the
middle of the dropdown.
Task- 2525928
closesodoo/odoo#70832
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Currently, traceback occurs when same attachments are sync with
form view and bottom chatter and removed from chatter.
So in this commit, on click of remove attachment dialog wait
till the attachment id is removed from list of attachments.
closesodoo/odoo#65093
Taskid: 2431478
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Description of the issue/feature this PR addresses:
It is currently quite difficult to differentiate users. Most of the time, people
don't take the time to upload an actual avatar so everybody looks the same. This
PR generates a custom avatar with the users initials and random color to
differentiate them. For res.users, res.partner and hr.employee, image fields now
hold the binary image and avatar are used to show the image or svg.
Current behavior before PR:
Avatar had only random colors and was being saved in database, being inefficient
Desired behavior after PR is merged:
A new mixin defines image fields and in case no image is set, it generates an
SVG image with the user's initials and random color.
closesodoo/odoo#69819
Task: 2404630
Related: odoo/enterprise#18199
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit allows to log a note and bypass notification process using a
template. The method _message_log_with_view has been added. This method
render the template using the given view and values (in kwargs) to make the
body before calling _message_log().
This process is done by the intermediary method _message_compose_with_view that
is now common to message_post_with_view and _message_log_with_view has it
follows the same template preparation process.
Task ID: 2459416
Linked ENT PR: odoo/enterprise#17553
As the mailing.list model has his own custom merge method, this model should
not be candidate to activate the generic merge method comming from data_merge
module.
This change is done here to avoid creating a bridge module in enterprise
only to add this flag. We can consider that the flag is linked to the custom
merge method itself. If a model has a custom merge method, it should be marked
as 'having a custom merge method'.
Task ID: 2459416
Linked ENT PR: odoo/enterprise#17553
Purpose of this commit is to prepare ground for future improvements by already
supporting QWeb rendering in ``mail.render.mixin``.
We temporarily support new field parameters allowing to tune the rendering
directly from field. Notaby choosing engine (jinja or qweb) can be done
from field directly. This is considered as experimental, used mainly to
prepare QWeb support.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
Prepares Task ID-27033 (QWeb in templates)
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
Using this mixin allows to hide details about jinja-based computation for
main fields used when posting messages or sending emails. Notably subject
and body computation that was duplicated in several addons are now done
in a mixin. It also eases their maintenance or evolution when qweb rendering
will be available. It also eases support of lang when necessary.
``mail.compose.message`` is still overriding default mixin behavior to keep
a minimal fix. Rewriting composer code is planned but will not be done with
this task. Here we keep current behavior, technically and functionally.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
COM PR odoo#70889
ENT PR odoo/enterprise#18352
UPG PR odoo/upgrade#2496
Co-Authored-By: Stéphane Debauche <std@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
This commits introduces a new mixin ``mail.composer.mixin`` used when sending
emails or notifications based on a mail template.
Main current purpose is to hide details related to subject and body computation
and rendering based on a mail.template. It also give the base tools to control
who is allowed to edit body, notably when dealing with templating language
like jinja or qweb.
It is meant to evolve in a near future with upcoming support of qweb and fine
grain control of rendering access.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
Co-Authored-By: Stéphane Debauche <std@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Currently ``mail.render.mixin`` offers rendering tools, some of them being
based on a ``model`` field. It allows to know which model to use to fetch
records on which we perform rendering. However this field is not defined at
mixin level but in inheriting models without being clearly implemented that
way (see ``mail.template`` or ``sms.template`` models).
In order to clean this mixin it is now defined at mixin level, using a
not stored computed field allowing to define how to find this model. Sub
models are updated accordingly.
Other cleaning is done in the render mixin
* rename ``_render_template_qweb`` to ``_render_template_qweb_view``
to indicate it works on views, not on raw qweb templates;
* extract some common available variables for rendering in a method then
called / upated for jinja and qweb views;
* correctly set same rendering context for jinja and qweb views rendering;
* allow to propagate an additional context from _render_field to sub
rendering methods;
* allow to propagate options through rendering methods (notably for escaping
or safe attributes in jinja);
* allow to specify engine used to render lang;
* clean or update some docstrings;
Some tests are also added, as render mixin lacks some more detailed test to
ensure various use cases will be correctly migrated to other engines like
QWeb.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
Prepares Task ID-27033 (QWeb in templates)
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
Co-Authored-By: Stéphane Debauche <std@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Before this commit, the className can be null and then this processing:
`this.className += ' o_clickable_m2x_avatar';` gives
'null o_clickable_m2x_avatar' in the class of the element classList.
This commit checks if the className is not null if yes, then we add the
the class otherwise the className is created in this mixins.
closesodoo/odoo#71461
X-original-commit: d25459e6cb
Related: odoo/enterprise#18605
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Martin Trigaux