Refactor the `load_views` API so it no longer sends multiple times the same
fields description.
e.g.
When `load_views` is called to get the kanban, tree and form views,
the list of fields of the model was sent 4 times:
- Once for each view, with only the fields used in the view,
in `['fields_views']['kanban']['fields']` for instance
- Once globally, with all the fields of the model, in `['fields']`
The goal of this revision is to change that so it sends the list of all fields
only once.
In addition, if a view contains x2many fields,
the fields description of the comodel is also sent.
It was sent in the `views` key of the view fields dict.
e.g.
When calling `load_views` of `res.partner` to get the kanban,
tree and form views,
the `res.partner` fields description was actually sent 6 times:
- Once for each view
- Once globally
- Once for each view of the many2many field `child_ids` of the form view, in
- `['fields_views']['form']['fields']['child_ids']['views']['kanban']['fields']`
- `['fields_views']['form']['fields']['child_ids']['views']['form']['fields']`
The change suggested in this revision is to:
- Remove the fields description for each view in `['fields_views']`.
As it no longer contains the fields,
the key becomes `['views']` instead of `['fields_views']`.
- Replace the dict key `['fields']` by `['models']`,
which is a dict with as key the model name and as values
the model fields description. It contains the fields description
for all models implied in the view:
the model of the main view and the model of all one2many and many2many fields.
With this change, the fields description will only be sent once by model
implied in the view.
In addition, the web client was getting the information about the fields
sometimes in the global fields description list (e.g. `['fields']`),
sometimes in the fields description list of the view type
(e.g. `['fields_views']['form']['fields']`),
making it a pain to try to make changes / performance gain
in these field description dictionaries, because you never knew in which dict
the web client was getting its info.
Now, as there is only one place to get the fields description from,
it's clearer and cleaner.
- one2many and many2many fields views are passed directly in the main view
architecture rather than being put in the `views` key
of the field description.
This is actually easier to treat by the web client,
and this will allow in a future work to cache an entire view in one block
of text rather than having to combine multiple cached blocks of text
to return one view.
- one2many and many2many fields which do not have directly embedded views
have their views directly injected in the architecture,
so the web client doesn't have to do RPC calls to `load_views`
for each one2many and many2many fields not having embedded views.
For instance, this allow to reduce the number of RPC calls to `load_views`
from 8 to 1 when loading the form of `product.product`.
Currently, this behavior is limited to 1 level deep but we consider making it
go all the way down in future works. We did not do it for the moment because
in certain cases it rises the processing time and the size (bytes) too much.
e.g. the sale.order view can be 5 levels deep,
meaning you can reach 4 dialogs on top the main view.
```
sale.order form > order_line > sale.order.line form > invoice_lines >
account.move.line form > asset_ids > account.asset form >
depreciation_move_ids > account.move form.
```
This will also benefit in future works to cache an entire view in one block
of text rather to having to combine multiple cached block of text
to get one view.
- `fields_view_get` becomes `get_view`.
As it no longer returns the fields description,
keeping the `fields` in the name `fields_view_get` no longer makes sense.
Hence removing `fields` from the method name, it becomes `view_get`.
As it gets renamed anyway, we take the opportunity to rename it `get_view`,
which is more in line with the general getter/setter guidelines
in the model object world.
- `_fields_view_get` becomes `_get_view`. For the same reasons than above.
- `load_views` becomes `get_views`.
This is not mandatory, there is no technical reason to rename `load_views` as
it practically sends the same info as before,
the view architectures and their fields description. Just in another way.
We just take the opportunity of this pull request to suggest a cleaner API:
`_get_view`, `get_view` and `get_views`.
- Arguments `toolbar=False, submenu=False` fo the methods
`_fields_view_get` and `fields_view_get` are converted to a kwargs `**options`
in `_get_view` and `get_view`.
The rationale is that submenu was already no longer used (deprecated)
and the mobile options is introduced.
The mobile options is necessary to tell the server to send the mobile views
for x2many fields (kanban instead of tree).
Instead of adding a new argument each time we add a new option to
`fields_view_get`, it seems wiser to have a kwargs `**options` to avoid
to re-write all overrides each time a new option is introduced.
- `_fields_view_get` returned a dict containing the arch in text and some of the
view information. Now, `get_view` returns a tuple with the view architecture
as an `etree` node, and the view as a browse record. The rationale is that all
overrides of `_fields_view_get` were about modifying the arch only
(e.g. changing the address format/re-organizing the address related field
nodes of the partner according to the company country).
To do so, all these overrides were doing `etree.fromstring` to parse the arch
which was sent in text to convert it to an `etree`,
then operations were done on the `etree`,
and then `etree.tostring` was called to convert back the arch to string.
With this change of signature to send the arch as an `etree`,
all these back and forth `etree.fromstring` -> `etree.tostring` are avoided,
allowing some performance gain and less code in the end.
- A cleanup of the keys returned in the dict of `fields_view_get`
has been performed in `get_view`:
- `fields` is removed, as explained above,
- `view_id` is renamed `id`,
- `name` is removed, it was unused by the web client,
- `type` is removed, it was unused by the web client,
- `field_parent` is removed, it was unused by the web client,
- `base_model` is removed, it was unused by the web client.
- `filters` is moved from the global dict returned by `load_views`
(now `get_views`) to the dict returned by `fields_view_get` (now `get_view`)
as it applies only to the `search` view type.
- Retro-compatible methods for the 3 methods
`fields_view_get`, `_fields_view_get` and `load_views` are provided,
with deprecation warnings in them.
- The web client could cache the model fields description
(as it already caches the views),
so it doesn't need to fetch them again if it asks for another view of a model
for which he already has the fields description.
If we do so, `get_views` could return only the list of models used by
the views, without the fields description as of now,
and the web client would then call `fields_get` independently only for
the models for which it doesn't have yet the fields description.
This would avoid the server to return the fields description
and to call `fields_get`, which is costly, for each `get_views`,
therefore gaining performances.
- Inject the views of the one2many and many2many fields all the way down,
unlimited depth level, as explained above.
- Cache with `ormcache` the architecture of back-end views.
This is already done for qweb views, it's not done for back-end views.
Therefore the postprocessing of the views is performed for each `get_views`,
which is costly, while the view architecture doesn't change for users
belonging to the same groups, according to the groups implied by the view.
This pull request is co-authored by
Aaron Bohy (aab) for the web client part and
Denis Ledoux (dle) for the server part.
Part-of: odoo/odoo#87522
Issue: when using Amazon's SES SMTP service they rewrite the Message-Id of all
outgoing messages. When someone replies, In-Reply-To contains the SES Message-Id
which we don't know. Threading is therefore broken. Amazon requires to remember
new Message-Id and handle it ourself, which is complicated [1].
Possible solution: copy the Message-Id to References in outgoing message as if
we were pretending that the message is part of a pre-existing thread with
itself. Since Amazon does not alter References it is kept during transport.
Replies will therefore contain both Amazon Message-Id and Odoo Message-Id as
well as original parent Message-Id in case of nested replies.
* ``In-Reply-To``: Amazon Msg-Id
* ``References``: Odoo Parent Msg-Id Odoo Msg-Id
Task-2643114 (Mail: Message-Id in references to ease thread formation)
[1] https://docs.aws.amazon.com/ses/latest/DeveloperGuide/header-fields.htmlclosesodoo/odoo#89328
X-original-commit: bc568747bdf92c6bbca400ce3ba11f6487679f3a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Followup of odoo/odoo@de7c119e66 where the parent finding was incorrectly refactored.
Indeed due to a typo new_parent was not updated. Instead of getting higher in
the parent chain until the first message, only the first parent's parent was
considered.
Moreover ``_mail_flat_thread`` is incorrectly taken into account. Due to the
hereabove issue it was not really impacting discussion channels, as anyway
parent finding was not working.
New parent management, depending on ``_mail_flat_thread`` is now
* ``_mail_flat_thread`` True: no free message. If no parent, find the first
posted message and attach new message to it. If parent, get back to the
first ancestor and attach it. We don't keep hierarchy (one level of
threading);
* ``_mail_flat_thread`` False: free message = new thread (think of mailing
lists). If parent get up one level to try to flatten threads without
completely removing hierarchy;
Tests show that parent is correctly flattened on business documents and left
untouched for channel-like documents.
Task-2822652 (Mail: fix parent message fetch / flattening)
X-original-commit: 86f21c1f384e37a4555b4b1ce4831904c8d40b6f
Part-of: odoo/odoo#89328
Before this commit:
There is a obsolete method _action_remove_members in tests which is not
needed now
After this commit:
Removed this obsolete method
Task-2824921
closesodoo/odoo#88988
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Python library currently holds a limitation when we use a formatted email
that is longer than 78 characters (e.g. "Long Company Name With Long Record
Name <email@domain.com>"). Python folds address if is longer than 78 chars
and a bad management of quotes breaks the reply-to. Even if anything should
technically be ok with the RFC python seems to incorrectly handle it (please
refer to [1] for more details and discussions).
Until this is finally sorted out we decided to avoid issues by shortening
reply-to. To avoid that issue when formataddr would return more than 78 chars
we return a simplified name/email to try to stay under 78 chars. If not
possible we return only the email and skip the formataddr which causes the
issue in python. We do not use hacks like crop the name part as encoding and
quoting would be error prone.
Task-2602862
OPW-2733513
[1] See https://bugs.python.org/issue44637closesodoo/odoo#89081
X-original-commit: d2d705708a11de68d8dd9d9edf62e0a33ddb066b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
To reproduce:
1. Start a meeting in Discuss or start a group conversation of V15, then try to leave this channel by clicking channel's x button in the page's left side `DIRECT MESSAGES` list.
2. After clicking `Leave` button in Confirmation dialog you will get Access Error prompt: Due to security restrictions, you are not allowed to delete 'Listeners of a Channel' (mail.channel.partner) records.
Cause and Solution: the computed field value:
Since in the middle of process, outdated.channel_id.channel_partner_ids doesn't contain current env.user, to bypass access rule restriction we need to use sudo().unlink()
closesodoo/odoo#88897
X-original-commit: b3d371a4380305a2ea8fd14c30432e6ddbd9cb35
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Even if ORM normally filters them out, no need to specify .id in domains.
This leads to better and easier to read queries / domains.
Task-2816580
closesodoo/odoo#85648
Related: odoo/enterprise#24911
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current access rule requires fetching all members of each channel, which does not scale.
Use is_member field instead, and make sure itself does not fetch all members.
task-2818759
closesodoo/odoo#88221
Related: odoo/upgrade#3422
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Most of the extensions of `_name_get` are very similar and only want to
search for the given string in multiple fields.
A lot of extensions also don't take into account the negative operators.
Some implementations were also really outdated and needlessly
complicated.
closesodoo/odoo#86588
Related: odoo/enterprise#25608
Signed-off-by: Raphael Collet <rco@odoo.com>
no need to select * in a query that looks like
select ...
from A
where exists(select * from B where ...)
we can instead use
select ...
from A
where exists(select 1 from B where ...)
closesodoo/odoo#88013
Signed-off-by: Raphael Collet <rco@odoo.com>
Before this commit, since https://github.com/odoo/odoo/pull/83574,
attempting to join a call through the channel guest page while being
logged as a portal user would give an acess error.
This commit fixes this issue
closesodoo/odoo#87995
X-original-commit: e6a637dc1d4e024c67b946fbe26a1b1e0dd144f3
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
PURPOSE
Cleanup code and flow of customer rating: routes, rating_apply, rating and
message creation and update.
SPECIFICATIONS
Cleanup code about rating controllers and rating_apply. Notably correctly
link a message to a rating once a feedback is posted, whatever the flow.
Update ``rating_apply`` to use either a token, either an existing rating to
udpate it and post a message. Always link the message and the rating to
be sure DB data are coherent.
This requires an update in several demo data to correctly set tokens on
ratings and use it in calls to ``rating_apply`` done in xml files.
Extract default subtype computation of rating_apply in a sub-method to allow
setting this parameter without having to deal with ``rating_apply`` details.
CODE CLEANUP
Split behavior that is generic but actually used only in project about stage
update based on rating. Move it directly in project. As it is used only once
and as generic approach is hardcoded based on fields names better keep it
localized.
Task-2812665 (Rating: Cleanup rating flow code)
Part-of: odoo/odoo#80707
Currently, when inviting members to a mail.channel using the "add_members"
method, it is not possible to signal to web client to automatically open that
conversation in a chat window.
This commit adds a parameter to that method to allow that behavior, and also
slightly adapts the notification handling to open the chat window accordingly
on the web client side.
This is necessary for the upcoming chatbot, where we want to invite operators
to the channel and make them see the new conversation immediately.
Task-2030386
Part-of: odoo/odoo#84000
Currently, when adding members to a mail.channel using the add_members method,
we always post notification message on the channel mentioning that someone has
joined the channel / was invited to join by another user.
This commit simply adds a method parameter allowing to disable that behavior.
This change is necessary for the upcoming chatbot, where we want to add members
but handle the join notifications differently.
Task-2030386
Part-of: odoo/odoo#84000
Current behavior :
When you delete a record (for example project.task), all the messages related
to this record aren't deleted.
This, in case a user has his notifications managed in Odoo, may prevent him
from accessing the History tab in the Discuss app because these messages are
linked to a record that doesn't exist anymore and it will raise a Missing Record
error
Steps :
*with demo data*
- Install Project
- Make Marc Demo notifications managed in Odoo
- Delete a task project to which Marc Demo is assigned
(*with Marc Demo*)
- Go to Discuss and try to access History tab
OPW-2764855
closesodoo/odoo#87732
X-original-commit: ee8feeb73c920827090b1a5ecf78e8b1d21bbae4
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Claude Thibault (thcl) <thcl@odoo.com>
Skip the confirmation step when wanting to get rid of a notification
for emails, sms or letters that were not sent.
Technical:
- All 3 wizards to confirm the discarding of the notification have been removed
(the ones for mail, sms and letter) have been removed
- The method to discard notification has been centralized in MailThread
(notify_cancel_by_type in addons/mail/models/mail_thread.py)
- This centralization has been done as well on the client code as the same
server code is called whether it is a mail, a sms or a letter
(in addons/mail/static/src/models/notification_group/notification_group.js)
- Existing front and back test have been adapted
- A test of notify_cancel_by_type for mail has been added
(addons/test_mail/tests/test_mail_management.py)
- add missing author_id in mail_notification demo data
Task-2752190
closesodoo/odoo#84452
Related: odoo/upgrade#3246
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit adds a name argument to the create_group method as it is
useful to create a group channel and set its name directly on the
create.
task-2685472
closesodoo/odoo#87703
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
In mail we currently create the invitation URL by concatenating the values when
needed. However this could be improved so that when this url is used in other
places we don't need to create it again. Therefore it makes sense to have a
computed field that does that for us.
task-2685472
closesodoo/odoo#87701
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
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>
Denis Ledoux