The get_model_definitions method returns default values for each field. Those default
values are wrong most of the time (dynamic values, reference to non created records on
the client side, ...).
task-2792108
closesodoo/odoo#87641
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The odoo.addons.web.controllers.main python module have been splitted
over multiple files on the basis 1 controller = 1 file. In this work we
adapt all modules to use the new imports.
A non-exhaustive list of where stuff have been moved:
* main.Home --> home.Home
* main.Session --> session.Session
* main.WebClient --> webclient.WebClient
* main.clean_action --> action.clean_action
* main.ensure_db --> home.ensure_db
The complete list is accessible in odoo.addons.web.controllers.main.
closesodoo/odoo#87571
Related: odoo/enterprise#25746
Signed-off-by: Raphael Collet <rco@odoo.com>
The group_public_id and group_id and subscription_department_ids
should only be used when the channel_type is 'channel'.
task-2766712
closesodoo/odoo#84813
Related: odoo/upgrade#3266
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
*: web, website_slides.
Specifying both side of a relation when seeding test data is cumbersome.
Let startServer method handle it.
task-2792108
closesodoo/odoo#86939
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Activity-level feedback method accepts attachment_ids but not its mixin-level
counterpart. This commit fixes that by adding the parameter. The activity-level
action_feedback_schedule_next method now also accepts attachments in addition
to the feedback, making the API coherent through all entry points.
At activity level ``action_done`` now goes through ``action_feedback``. This
means it now has two main methods
* ``action_feedback``;
* ``action_feedback_schedule_next``;
All methods finally end up calling ``_action_done`` and correctly propagate
feedback and attachments. We have a bit less entry points with possible API
changes.
Test mail models are updated to be able to use this small addition.
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#86393
Before this commit:
When user shares the invitation link of the channel(groups restricted), guests
are allowed to access it.
After this commit:
Guests will not be allowed to access channels that are restricted to groups.
Task-2679184
closesodoo/odoo#87004
X-original-commit: ea3232c111546ec636f543db912bf0e2a7ed345b
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose
=======
The method find_or_create of res.partner overwritten in mail does not
take into account the parameter assert_valid_email. This commit adds a
simple check and test.
Task-2799577
closesodoo/odoo#86943
X-original-commit: 7a07b365370d03e963aa7f7d9d19df7ee33e8a1c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Make the channel_type required in UI and add SQL constraint for the database.
task-2774970
closesodoo/odoo#85146
Related: odoo/upgrade#3273
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*: hr, hr_holidays, im_livechat, mail, snailmail, test_mail, website_livechat,
website_slides.
This commit will remove the need to duplicate models definition for
test purposes. Indeed, for now, we need to mock the model definitions
on the client side. Those models definitions are often very different
from the ones found on the server.
This approach will allow us :
- to ease model definitions during tests
- to get closer from the real models
task-2767820
closesodoo/odoo#84828
Related: odoo/enterprise#24486
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit:
In discuss, the group DM default name does not contain any guest names in it.
After this commit:
Group DM default name will also take guest names along with other user names.
Task-2664859
closesodoo/odoo#86130
X-original-commit: 41f4c5741097b09c372406bbbd5364314bff6d1b
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
It's currently confusing: the default value is already 'groups', but the create
method is actually giving another default.
task-2749643
closesodoo/odoo#86075
X-original-commit: 31dfc797bc0fb163b6e32d3fe2195791b674f00c
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Followup of odoo/odoo@c178a7829f where a failure type renaming was badly
propagated. This commit fixes failure type naming allowing to correctly
distinguish a missing email from an invalid email.
Task-2684479 (Mail: Better send error storage and display)
X-original-commit: 1a08b3f4b3aa849549783348c51c393a1f84a409
Part-of: odoo/odoo#85864
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
Specify 'channel_type' explicitly in channel_create. This makes the
method more clear and decoupling from default value.
Once the default values changes, the method can work as expected as well.
task-2767635
closesodoo/odoo#84867
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps :
- Make sure the Admin is notified by mail;
- Set an Alias Domain for the company.
- Create a Project with an Alias e-mail address.
- Send an e-mail to this alias.
Issues :
In the admin mailbox, see the signature is: `<p>-- <br/>False</p>`, which means two issues.
- It is not unescaped from Html.
- The content of the signature is 'False'.
Cause :
When no user is related to the sender of the mail, we manually set a signature.
- It was written between html tags, so it should be sanitized.
- Its content was author.name, yet author is a partner, so if there is
no partner, name is False.
Fix :
- Sanitize the html code of the signature.
- If there is no partner for this sender, use email_from, or else ''.
opw-2728483
closesodoo/odoo#84329
X-original-commit: a1ac9c8171742c5622e5f310cec2fe4ab53c2717
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Onockx Audric (auon) <auon@odoo.com>
- Open any record with a chatter (i.e. a SO)
- Log a note with a mention to any res.partner
- Edit note and save
The mention is not a link anymore, but just plain text.
During edition the list of mentioned partners is not retrieved correctly,
preventing function that generates links from mentions to work properly.
On client-side, a variable named MentionedPartners is used to generate
mention links when posting a message.
It should contain the id and name (to match the mention text) of each
mentioned partners.
During edition, MentionedPartners is empty, leading to this issue.
As the list of mentioned partners is stored in message model in partner_ids
field, "id" and "name" of partner_ids will be retrieved and added to messages
data when requested by client side.
This will allowed to populate MentionedPartners with all required data.
Note that retrieving "name" from partner_ids will add an extra query,
as seen in the modified test.
opw-2739665
closesodoo/odoo#84152
X-original-commit: 510764730057b20a1706ae20d50549e280f7f9a7
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
- Go to Email Marketing and create a new mailing
- Add Masonry snippet in mail body
- Send a test mail
The picture of the Masonry snippet is missing.
The masonry image is displayed with CSS via background-image attribute.
There are 2 causes for this issue:
1) The relative url cannot be converted to an absolute one.
This is due to the " entity used to surround the url that is not detected.
style="background-image: url("/web/image/mass_mailing.s_masonry_block_default_image_1");"
2) html_sanitize is applied to mail body, but html_sanitize doesn't allow
background-image style attribute.
opw-2735636
closesodoo/odoo#83998
X-original-commit: cdcef228aa30d7dd4081fa25a1aab4811acda3ad
Signed-off-by: Antoine Guenet <age@odoo.com>
QWeb is the primary templating engine used by Odoo. It is an XML
templating engine and used mostly to generate XML, HTML fragments and
pages.
To create new XML template, please see :doc:`QWeb Templates documentation
<https://www.odoo.com/documentation/15.0/developer/reference/frontend/qweb.html>`
In **input** you have an XML template giving the corresponding input
etree. Each etree input nodes are used to generate a python function.
This fonction is called and will give the XML **output**.
The ``_compile`` method is responsible to generate the function from the
etree, that function is a python generator that yield one output line at a
time. This generator is consumed by ``_render``. The generated function is
orm cached.
In the graphic below you can see theresume of the call of the methods
performed in the IrQweb class.
Odoo
┗━► _render (returns MarkupSafe)
┗━► _compile (returns function) ◄━━━━━━━━━┓
┗━► _compile_node (returns code string array) ◄━━━━━━━┓ ┃
┃ (add technical directives: t-inner-content, t-tag) ┃ ┃
┣━► _directives_eval_order (defined directive order) ┃ ┃
┃ ┃ ┃
┣━► _compile_directives (recursive) ◄━━━━┓ ┃ ┃
┃ ┣━► _compile_directive ┃ ┃ ┃
┃ ┃ ┗━► t-if ━━► _compile_directive_if ━┫ ┃ ┃
┃ ┃ ┗━► t-foreach ━━► _compile_directive_foreach ━┫ ┃ ┃
┃ ┃ ┗━► t-* ━━► ... ━┛ ┃ ┃
┃ ┃ ┗━► t-inner-content ━━► _compile_directive_inner_content ◄━━━━┓ ━┛ ┃
┃ ┃ ┗━► t-tag ━━► _compile_directive_tag ━┫ ┃
┃ ┃ ┗━► t-call ━━► _compile_directive_call ━┫ ━━━┛
┃ ┃ ┗━► t-out ━━► _compile_directive_out ◄━┓ ━┫
┃ ┃ ┗━► t-field ━━► _compile_directive_field ━┛ ┃
┃ ┃ ┃
┗━━┻━► _compile_static_node ━┛
Part-of: odoo/odoo#81024
We are currently lacking an index with (author, failure) due to the information
being spread out in two different tables which are both rather big (there are a
lot of non-failure messages for the current user, as well as a lot of failure
messages for other users), so the fetch of failures for the current user can
become extremely slow (> 20s).
With this new index, the query takes less than 1ms.
task-2742946
closesodoo/odoo#83451
Related: odoo/upgrade#3204
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose
=======
A field `use_google_gmail_service` has been used in stable to define
a mail server which use Gmail authentication.
But now that the fields `smtp_authentication` exists, we want to use it
to simplify the mail server form view. For the incoming mail server,
the field `server_type` will be used for the same purpose.
Add a new field to have the option to install `google_gmail` in the
main settings page.
Task-2170676
closesodoo/odoo#83413
Related: odoo/upgrade#3199
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current behavior:
After creating a group chat in the discuss app you were not able to close it.
Steps to reproduce:
-Create a group chat with more than one user in the discuss app
- Try to leave it
- You get an access error
opw-2736464
closesodoo/odoo#83717
X-original-commit: cc1c132ee092368e77108f327ecdc5a6d2c490a6
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Activities and mailing trace are linked to documents through a model and
a many2one reference field. The latter one is required but is implemented like
an integer field, meaning writing 0 is actually a valid value for 'required'.
In this commit we add a constraint to ensure we never update activities with
a void res_id value. Same for mailing traces. This allows to remove the
required attribute on fields to avoid having redundant sql constraints.
Source: internal feedback about activities with 0 as res_id
Task-2694133
Part-of: odoo/odoo#81292
Before this PR, the query from _channel_last_message_ids could take a
significant amount of time.
This add an index to speed up the query.
task-2746108
closesodoo/odoo#83476
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Expected Behaviour
When a user get a mail from the data cleaning about records to examine, the View button should be linked to the same url as the 'here' hyperlink or not be in the e-mail.
Observed behaviour
Clicking the link in the View button lead to an error page
Reproducibility
This bug can be reproduced following these steps:
1. Duplicate a contact
2. Wait for the scheduled task to launch
3. Click on the View button of the mail you'll get about te duplicate
Problem Root Cause
This issue is coming from the way we create the 'View' and 'View Task' button, and can't be changed easily. The easier way to fix this issue is then to hide these button
Related Issues/PR
opw-2674138
closesodoo/odoo#83284
X-original-commit: 3a61747b366a315488837e2e560b305e89217dbd
Signed-off-by: Hendrickx Anthony (anhe) <anhe@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
As an overridable _neutralize model method was added in a previous
commit, the method is now implemented for various models.
closesodoo/odoo#67825
Related: odoo/enterprise#19042
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
PURPOSE
Allow to somehow decorate notification emails headers with a subtitle holding
the record name and some main informations.
SPECIFICATIONS
Next to access button in "Pay Now" notification email, display a subtitle
for some of the main "Send by email" based email flows. It should be something
like 'Invoice REF/01 \n35€ due 11/2022' for account.move or equivalent for
sale.order models.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
Purpose of this commit is to add potential groups but de-activate them by
default. Indeed each group require about 20 queries for rendering and
sending. If no specific behavior (access button, content) is made for this
recipient group it can be included in lower-version of the group.
Specifications
* de-activate portal group in mail as it has no additional rights compared
to customers;
* add follower group but de-activate it for the same reason;
* activate portal group in portal_mixin and include links to the record in
notification emails, using standard mail/view link. ACLs are managed in
each specific model, generally based on followers;
Update a test in test_mail as it was playing with public and portal users
that are now not really differentiated when sending notification emails.
Better have more real-life scenarios with portal and internal users.
Task-2739294 (Mail: Batch recipients fetch and improve its usage)
Part-of: odoo/odoo#82167
Purpose of this commit is to improve notification recipients computation.
Code cleaning
* make it batch enabled. Currently it works only for a single record. It
should evolve towards real multi computation, allowing to prepare post
and notification in batch;
* better manage multi users. Now when several users are linked to the same
partner, we try to find an internal user or fallback on share user. This
is cleaned compared to a distinct done previously;
* support recipients without subtype (pids + records) as a new case to
include follower computation;
Improvements
* include follower status if linked to records (is_follower can be used
notably in link computation to redirect to the portal);
* fetch partner lang directly in the SQL query. While fetching partner data
let us add its lang. That way it will be easier to improve lang support
in layouts;
Task-2739294 (Mail: Batch recipients fetch and improve its usage)
Part-of: odoo/odoo#82167
Add a constraint directly at db level ensuring no duplicated notification
exist on partner / message pair, if partner is set. Partner can be void notably
with SMS notification process which may target numbers directly.
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
In order to make fields a bit more explicit, let us rename "add_sign" to
"email_add_signature". It indicates it is linked to the email notification
process, adding the signature depending on the notification layout itself.
This is done on both mail.message and mail.compose.message models. It is
also updated as rendering value parameter used in notification emails.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
A method that actually runs on recordsets should not have a model decorator.
Even if there is no issue this is may be confusing.
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
Purpose is to support portal parameters in ``_notify_get_action_link``. This
method generates a ``mail/view`` link that may redirect to frontend e.g. with
portal. We already support parameters coming from auth_signup and tokens from
portal. Supporting pid / hash allowing to post on documents using the frontend
chatter is the next step to generic links. This is just adding them to the
accepted like, not changing any current behavior.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
If we call ``MailFollowers._get_recipient_data()`` with pids parameter being
set to None there is a crash that is easily solved( list(None), should take
list fallback before hand).
Task-2739294 (Mail: Batch recipients fetch and improve its usage)
Part-of: odoo/odoo#82167
PURPOSE
Purpose of this commit is to cleanup flow of values going through message_post
and its sub methods until email generation for notifications.
SPECIFICATIONS
Ensure some values are given directly when creating message linked to post
methods to avoid browsing message when value is not known. Notably make
signature propagation (add_sign) more explicit in message_post and its sub
methods (notify, log, ...).
Prepare future language related improvements by allowing to force company and
lang values for rendering context. Also add ``is_html_empty`` tool method to
use it in notification templates. It will be used notably to check for empty
html blocks, e.g. user signature.
Rename some internal variables to better understand their purpose.
Finally update some outdated and/or badly indented docstrings.
Task-2726501 (Mail: Propagate message values in post methods)
Part-of: odoo/odoo#82167
PURPOSE
Purpose of this commit is to clean notification email values generation
while keeping possibility to override and tweak values. It now has clean
hooks on base mail value and final mail values.
SPECIFICATIONS
Base mail value are values independent from recipients. It allows notably
to tweak values depending on current record without having to browse and
access record for every recipient, saving unnecessary computation.
Final mail values are recipients-dependent and are the values that will be
use to create the final ``mail.mail``. With a mechanism of optional additional
values + hooks for base and final values it should be possible to keep any
custom behavior already implemented with a cleaner interface and code flow.
See notably odoo/odoo@b1a5bf95f8 for example of why some code exist just
for hook purpose.
As a side note, light variable renaming is performed (email -> new_email)
to avoid shadowing email.
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
PURPOSE
Global purpose is to rename some methods and add some docstrings to clean
API of notification methods used in mail thread. Notably use _notify_thread
prefix for main methods, and _notify_by_'mean' for tool sub-methods.
SPECIFICATIONS
Remove unused arguments coming from old implementation and usage. They were
introduced notably for performance reason when cache was more often invalidated
which is not the case anymore. Anyway when parameters are unused it is always
better to remove them.
Remove ``notify_by_email`` parameter in ``_notify_thread``. It is only used
in channels to avoid notifying people of some automated notifications. The
same behavior has been cleanly implemented at odoo/odoo@018820d .
Rename methods, starting with ``_notify(_records)`` to ease their grouping
and understanding. Add some additional prefixes like ``_notify_by_'mean'``
and ``_notify_get_recipients`` for recipients related computation. Add some
docstrings, notably when parameters usage is not clear.
Some linting is also performed in updated actions, just to lessen styling
issues notably on runbot.
This commit should not change anything functionally as it contains only
some renaming and docstrings updates as well as some outdated parameters
removal.
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
Issue
-----
Via the field prefetch mechanism, when we need a value of one field
(not in cache of course), the ORM will prefetch all fields
(which has the attribute to `prefetch=True`, the default value of this
attribute is `True`) for all record ids in `_prefetch_ids`.
Then, for each translate fields (where translate is not a callable)
the ORM need to make a `LEFT JOIN` on the `ir_translation` to fetch the
translated value. For big model, it leads to a simple `SELECT` with
several `LEFT JOIN` on ir_translation but each LEFT JOIN have a cost
in the planner time (a small cost in the execution time) of PostgreSQL.
By example, for `product.template` (stock/sale/purchase installed),
there are 6 LEFT JOIN to get all translated fields (5 of this
fields are rarely used).
Proposed solution
-----------------
Deactivate the prefetch by default for all translate fields expect if
this field is the `_rec_name` of the model (which is more likely to
be used).
In the example on the `product.template`:
Without prefetching the translated fields, there is only one LEFT JOIN
(the name, which is translated but is the `_rec_name` of the model).
With the 6 translated fields to fetch, the
query takes 5 ms to plan and 2 ms to execute VS with 1 translate field,
it 1 ms to plan and 1.5 ms to execute.
Side change note
----------------
- All translate of fields of `website.seo.metadata` should be prefetch
to avoid lot of website errors (it is because, website put in cache data
in sudo before reading it without sudo)
- `description` (`mail.message.subtype`), `subject` (`mail.template`),
`body_html` (`mail.template`) should be prefetch to avoid lot of extra
query from mail module.
- `vat_label` (`res.country`) should be prefetch to avoid a extra query
for each website page.
- Increase some queryCount (when it is legit, due to `subtitle` of
`blog_post` or `description` of `event.type.ticket`, etc)
task-2738029
closesodoo/odoo#82896
Signed-off-by: Raphael Collet <rco@odoo.com>
Attachments of the chatter didn't update when a log with an attachment was deleted
Steps to reproduce:
1. Install Sales app
2. Open any sale
3. Create a log note with an image attached
4. Delete the log note
5. The image is still in the sale's chatter attachments
Solution:
When deleting an attachment, send the info on the current partner's bus
OPW-2732793
closesodoo/odoo#83199
X-original-commit: f5f09b7c73bc7a5243a3b6edcfa5d047de33d95e
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
tsm-odoo