The main goal of this commit is to reduce the size of the registry by
removing the (almost) useless __last_update field.
Statistics # of fields with all modules installed:
before 30184 fields, 1299x last_update (4.30%)
Before this commit, the computed field __last_update was added on every model.
The idea behind this field was to have a computed field that had either
the write_date or the create_date if the write_date was empty. However,
the write_date is always written, even on creation, making it useless
to have the computed field __last_update
After this update, we completely remove from BaseModel:
* __last_update
* CONCURRENCY_CHECK_FIELD that was always defined as "__last_update"
* _compute_concurrency_field that was the compute function for __last_update
closesodoo/odoo#105739
Task-id: 3062140 (part of 3062137 improve registry load time)
Related: odoo/upgrade#4038
Related: odoo/enterprise#33939
Signed-off-by: Raphael Collet <rco@odoo.com>
this commit improves the performance of importing translations by
1. groupup udpating data for different languages and different modules
2. read model_terms translations data directly with xmlid to get rid of fetching
data from ir_model_data
for modules:sale_management, point_of_sale, industry_fsm, helpdesk, mrp, mrp_plm
(62 installed modules)
time for test_language_install is 45.14% less
for all modules:
time for test_language_install is 68.03% less
closesodoo/odoo#107332
X-original-commit: 727ef9e0a2ca93089b472eb1313117fee8dc876d
Signed-off-by: Raphael Collet <rco@odoo.com>
Some mail clients set a wrong content-type for PDF attachments, they
set `binary/octet-stream` which doesn't exist[^1]. Odoo would crash
with a traceback in case it tried to extract the content of such
malformed attachment because Python doesn't know how to decode such
content-types.
Looking at the actual content of the emails we received, we would had
expected the content-type to be `application/octet-stream` instead. It
is fair to assume that the mail client software is buggy or poorly
configured and that it assumes that `application/octet-stream` and
`binary/octet-stream` represent the same thing.
Following Postel's Law[^2], it is better to still handle those malformed
emails, assuming the content-type is `application/octet-stream`.
opw-3030113
opw-2716507
[^1]: https://www.rfc-editor.org/rfc/rfc2046#section-3
[^2]: https://en.wikipedia.org/wiki/Robustness_principleclosesodoo/odoo#107317
X-original-commit: e6169325b968711a0a28444818b34aa1932a6bae
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Julien Castiaux <juc@odoo.com>
Warn user and alias responsible when model creation fails on incoming
message due to alias mis-configuration.
Alias custom default values that references archived or deleted records can
prevent the record to be created when receiving an email.
Unfortunately, correcting values on the fly has too many downsides:
- as the value cannot come from nowhere, we would probably end up with
corrupted record like a task without a project
- as errors are silent, lots of suboptimal record could be created before it
is corrected
- as the code would have to deal with different kind of updates, it would be
heavily depend on the framework meaning additional maintenance cost
- the attempt made had also a performance cost by using savepoint which we
want to avoid
For all those reasons, we have decided to warm the user rather than trying to
solve the problem automatically.
The users are warned:
- through a bounce email sent to the sender and alias responsible
- in the alias interface through an alias status present in the list and the
form view
Technical notes:
- They are multiple kind of errors: error in the message (ex.: user not
authorized to send to a specific alias), error in the alias (ex.: dangling
reference in alias_defaults), other error (ex: technical error like a
service unavailable when receiving the message). Here, we want only to detect
alias error and skip other errors. So rather than doing a big try except around
_message_route_process, we have selected the spot where we should detect alias
error:
-- in _alias_get_error_message where we distinct a message error from an alias
error
-- in inside _message_route_process where record are created using
alias_defaults (custom values with reference to record that might have been
deleted since the alias creation)
- In test, we call mail.thread message_process with sudo as it is the case in
real use case (processed when fetching mail). It is needed as in some test
alias status are modified.
Task-2675209
closesodoo/odoo#101019
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* = crm, mail, survey, test_event_full, website_event
To increase readability and performance, use f-strings where appropriate
(multiple concatenation +- formatting).
Note: Also removing unnecessary string concatenation with `%` for `(i)like`
in domains definitions.
Task-2977548
See odoo/enterprise#31156closesodoo/odoo#99811
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
PURPOSE
Purpose of this task is to cleanup attachment management done in generic mail
models overrides and move it in account as model overrides.
SPECIFICATIONS
Account_edi and various l10n submodules hold some custom code to generate and
handle EDI attachments. It is used to add attachments linked using AccountMove
specific 'edi_document_ids' field when sending emails based on templates.
Currently MailTemplate is overridden in accounting modules to hold code related
to AccountMove and AccountEdiDocument attachments manipulation. This is linked
to EDI and report naming, not mail specific. This should therefore not be
implemented at template level, but in those specific models.
For that purpose we introduce a method in MailThread that allow to handle
attachments when being in a template context. An override in account_edi
allows to implement its specific behavior.
By the way an old docstring in l10n_it_edi that was quite unrelated to the
override is also removed, as it was more confusing than helping.
Task-2792146 (Mail: Move model-dependent code from composer / template)
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#106658
PURPOSE
Purpose of this task is to cleanup attachment management done in generic mail
models overrides and move it in account as model overrides.
SPECIFICATIONS
Update addons
* in purchase and sale: context key update should be done at message_post
level, especially this is not used in mass mailing mode;
* in website_sale: code to update sale order to avoid sending recovery
emails several times belongs to a "post hook" method on sale order model;
* in loyalty: remove a deprecated / unsupported 'mark_coupon_as_sent' key;
Task-2792146 (Mail: Move model-dependent code from composer / template)
Part-of: odoo/odoo#106658
Purpose of this commit is to try to make code a bit easier to follow using
dicts, sets and tuples, as well as updating some variable names.
Also rename the method to be clearer. Tools methods may omit the namespacing
to avoid too much confusion in naming.
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#106658
Purpose is to make a section that will cover pre- and post- process methods
for posting or mailing records.
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#106658
Purpose of this commit is to use the newly introduced feature to log a message
when adding or removing an entry in block list of emails in email marketing
application.
Logging itself is improved, as it now contains
* source of the request (unsubscribe link, or manual ask through the portal
unsubscription page);
* link to the source mailing;
* link to the document that generated the click (a mailing contact, a sales
order, ...);
Task-2710804 (Mail: Clean MailThread API)
Prepares Task-2150462 (Mass Mailing: Unsubscribe flow refactoring)
Part-of: odoo/odoo#106568
Add possibility to add a message when adding or removing a blacklist entry
for both mail and phone_validation (used for SMS). This replaces the
``action_remove_with_reason`` method.
When updating active flag this is added as a tracking note to avoid having
several messages. Indeed message is concatenated with the tracking itself
instead of adding message for tracking + a message for the log itself. When
a new record is created, a note is logged.
Task-2710804 (Mail: Clean MailThread API)
Prepares Task-2150462 (Mass Mailing: Unsubscribe flow refactoring)
Part-of: odoo/odoo#106568
The goal of this revision is to add a group
`mail.group_mail_notification_type_inbox` which is granted
automatically when the user `notification_type` is set to `Inbox`
to be able to easily hide the filter `Unread messages` when
the user uses the `Email` notification type,
by simply adding `groups="mail.group_mail_notification_type_inbox"`
on the filter rather than overriding `_get_view` in every model.
The code overriding `_get_view` of `project.task`
to hide the filter "Unread messages" replaced
in this revision initially comes from
odoo/odoo@da868d28e2
> - In project.task search View:
> - the filter for unread messages should be visible only if the current user
> managing his notifications in Odoo
The above revision was part of the task 2844212
closesodoo/odoo#104328
Related: odoo/enterprise#33338
Related: odoo/upgrade#3996
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
When calling ``_render_fields`` asked options are now considered as more
important compared to options defined in field itself (using render_options).
Purpose is to allow to force some options when necessary.
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#106072
Due to recent improvements (Jinja -> Qweb, safe rendering) rendering API
supports several ways of giving options to the rendering process. Those
have mainly two usage
* ``preserve_comments`` : keep comments in rendered HTML, used notably
in mass mailing or digest to keep browser-specific comments;
* ``post_process`` : perform a post processing on rendered HTML, used notably
to process local links and add tracking to shortened links;
All those are now given directly inside an optional ``options`` parameter
given to ``_render_field`` and its sub-method ``_render_template``.
They can also be defined as field level, using ``render_options`` field
parameter. Some fields are updated
* composer mixin body (which impacts all inheriting models, notably
mail composer, survey and elearning invite wizards as well as appraisal
and appraisal feedback): post processing is now always done by default.
It was already done manually in calls that can be simplified;
* mail template body_html: post processing is now always done by default. It
was already done manually in calls that can be simplified;
* mailing body_html and preview are now post processed by default. It was
already the case in testing wizard. Preview is updated to avoid post
processing of links, as it was before. Remaining use case is the sending
which uses the mail composer, therefore was already post processed;
Finally some 'compute_lang' are explicitly added in _render_field calls in
order to be explicit on what we want, instead of being unsure.
Task-2710804 (Mail: Clean MailThread API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#106072
In this commit we support calling rendering methods on void or falsy record
sets. Currently some rendering methods prevent from having 'None', some do
nothing specific. As Qweb or inline template support rendering on void records
we can safely support rendering on [], (), [False], [None]. Returned result
will either be void, either contain the rendered on void record for the
False or None key.
In this commit we also add a protection against trying to render a non
existing field. Instead of raising a KeyError, a ValueError is raised with
a clearer error message.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#106072
Some cases require usage of Markup in order to correctly display HTML content
and avoid escaped or invalid statements.
Fix: in hr_recruitment, support default_job_id from context, easing display
of job's alias in empty list helper.
Task-3074357
closesodoo/odoo#106061
Related: odoo/enterprise#34139
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose is to try to have code easier to read and to update by having a
common way of sorting / writing code. Reorder some fields definitions and
dictionaries, update docstrings, ... in mail applications or when invoking
mail thread API.
Additional stuff worth noting here
* add some tagged in tests helping debugging / choosing tests to execute;
* in a test about mail generation with server action: correctly check
body_html field, not body which comes from the mail.message inheritance
(currently filled due to a side effect but actual field to check is the
html one);
* add same check on input for ``_render_template_qweb`` as done on other
rendering methods (even if rendering on [False] should be supported);
* move code translation update from specific tests into main test class
(code update due to new translations, followup of odoo/odoo@f8c2b02abe);
Some test linting done here
* reorder mail_render tests, remove some duplicated tests;
* reorder mail_template tests, remove some duplicated tests;
Task-2710804 (Mail: Clean MailThread Posting API)
closesodoo/odoo#106025
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose is to cleanup code: stop using help parameter name (use help_message as
help is a keyword), try to call super(), ...
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#105992
When a record was deleted, the related messages were remaining in discuss
front-end causing an error when the user was clicking on them. This solves the
problem by removing messages in the front-end as soon as they are deleted.
Task-2960281
Part-of: odoo/odoo#99371
Opening a DM chat with someone for the first time automatically pins
that chat for correspondents (i.e. the chat appears in Discuss), even if
no message has been sent yet. This can be unsettling for the person who
didn't create the chat but finds themselves with an unsolicited chat
pinned with no message.
This commit solves the problem by explicitly writing is_pinned to False
for the member that is not the current user.
Task-3028156.
closesodoo/odoo#104243
X-original-commit: 395bbc0ab2c2fc2eaee9d2bbe42b507fc84ee83a
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Unlinking a model during uninstallation can potentially fail when the query
removing any related mail activity types fails. This happens when such a record
is still referenced in the mail_activity table. Explicitly removing related
mail activities (as is done for the activity types and other related mail data)
resolves the issue.
Two tests are added, one that demonstrates the general flow and a regression
test triggering the behavior that caused a bug in the uninstall procedure of
the hr_holidays module.
closesodoo/odoo#104152
X-original-commit: b315f7f562fc84a09d99d6e7676567eb6f285402
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: De Caluwé Tom (tdc) <tdc@odoo.com>
Some of our current bus notification only insert data in the models system. We
can now simplify the way we handle them by using a generic `mail.record/insert`
handler.
closesodoo/odoo#102863
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
BUE
Steps to reproduce
- go to Apps, switch to studio and create and create a new app.
- on the form view, add a Many2one field related to 'Sales Order'.
- add a Ralated Field, related to 'Sales Order > Total'. You will be
presented with a prompt informing you that you need a currency field
on the model. Click 'OK' to add the currency field.
- again, add a Ralated Field, related to 'Sales Order > Total'.
- close Studio, fill the form you just created and save.
- switch back to studio and, again, add a Ralated Field, related to
'Sales Order > Total'.
You will be met with a traceback.
FIX
Actually defining a currency field on currency fields is mandatory. We
don't have to provide a fallback, hence we don't have to fix the fallback.
Simply remove it.
Task-3012648
opw-2951697
Closesodoo/odoo#94831Closesodoo/odoo#94962closesodoo/odoo#102918
X-original-commit: 899f3b4897f34576d502cf442ab7059c489870dd
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit the neutralize system introduced in v16 was using ORM
methods in order to change appropriate records. Although flexible, this approach
could lead to call some methods with side effects while neutralizing
(eg: overloads of write).
This patch converts the neutralize system to a safer "inert" SQL based approach
by migrating the generic method _neutralize to SQL files exposed in the
data folder.
Task id: 2961687closesodoo/odoo#102792
X-original-commit: e5dbded9bb363351feff7ca8a56c7f8a6860f492
Related: odoo/enterprise#32580
Signed-off-by: Fabien Meghazi <fme@odoo.com>
The goal of this task is to review the copywriting of the tooltips
because some of them are not correct in English and others are not
valid anymore. This is also a good opportunity to make an inventory
of the tooltips we have and to add some that could be missing.
task-2860991
closesodoo/odoo#102179
X-original-commit: 5e4cf8f9f6a4372f45aa04a5965f8073bb4ea68a
Related: odoo/enterprise#32298
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Co-authored-by: Mahendra Barad <mba@odoo.com>, Prakash Prajapati <ppr@odoo.com>
Allow our users to modify mail template more easily
- make the list accessible from the settings
- give them a link to update relevant views to update header/footer
- make the list and form of templates more readable
- add a description on templates, allowing to describe their usage
In order to better filter templates, a new category field is added that
is computed based on active flag, description being set and the template
having an xml ID. Master templates are active, with a description and an
xml ID.
Update master data to add description on some templates.
task-2944770
closesodoo/odoo#101730
X-original-commit: dfa867343ee8842f3f127ac62584fd471b41dde1
Related: odoo/enterprise#32079
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If website is installed, the login page of Odoo has opengraph meta that will be
used to create link preview on mention and channel link.
This PR add a xpath condition to always ignore mention and channel link in the
message body.
Part of task-3000274
closesodoo/odoo#101678
X-original-commit: eb032a5c36af6402b79ae768ce29b3d84eacf3b7
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Debondt Didier (did) <did@odoo.com>
Before this PR, the `_mockIrWebsocket__updatePresence` route of the
bus mock server could lead to errors when no im status ids were
provided. This commit fixes this issue by ensuring im status ids
were passed before calling `_mockIrWebsocket__getImStatus` method.
Moreover, old longpolling routes were still present on the bus mock
server. This commit removes these routes.
closesodoo/odoo#100583
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Transform the /websocket/update_bus_presence route to type='json'
which makes more sense as a POST than a get, seeing it does things with
a parameter and doesn't return anything.
Also fixes the _update_bus_presence method that leads to access errors
when accessed from HTTP when the user is the public one (only portal/
internal users should update their presences).
Part-of: odoo/odoo#100416
*: bus, hr_holidays.
The `/bus/im_status` route polls the server every minute in order for
the user im_status to be up to date. This commit removes this poll
by sending the im_status on the bus when updating the current user
presence.
Moreover, before [1], the user bus presence was updated on each poll.
When the user didn't poll for 50 seconds, we assumed the user was
disconnected. Since [1], the bus presence is updated each 30 seconds
by the `im_status` service. This is too frequent: there is no need
to update the user presence so often.
In order not to overhelm the server with unnecessary requests, the update
presence interval as well as the delay to be considered disconnected
have been updated: the former from 30 to 60 seconds, the later from
55 to 65 seconds (assuming that a user that has missed an update
presence tick is disconnected).
[1]: odoo/odoo@a5623d2closesodoo/odoo#100249
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Website: the context install_filename='dummy' is used to prevent
arch_updated from becoming True while updating translations of
ir_ui_view.arch_db (if arch_update becomes True, test_inherit_specific
fails)
Fuzzy search for jsonb translated fields has been adapted in the case of
website. It may require some refactoring later.
Translated fields no longer use the model ir.translation. Instead they store
all their values as JSON, and store them into JSONB columns in the model's
table. The field's column value is either NULL or a JSON dict mapping language
codes to text (the field's value in the corresponding language), and must
contain an entry for key 'en_US' (as it is used as a fallback for all other
languages). Empty text is allowed in translation values, but not NULL.
Here are examples for a field with translate=True:
NULL
{"en_US": "Foo"}
{"en_US": "Foo", "fr_FR": "Bar", "nl_NL": "Baz"}
{"en_US": "Foo", "fr_FR": "", "nl_NL": "Baz"}
Like before, writing False to the field makes it NULL, i.e., False in all
languages. However, writing "" to the field makes its value empty in the
current language, but does not discard the values in the other languages.
Here are examples for a field with translate=xml_translate:
NULL
{"en_US": "<div>Foo<p>Bar</p></div>", "fr_FR": "<div>Fou<p>Barre</p></div>"}
Change for callable(translate) fields: one can now write any value in any
language on such a field. The new value will be adapted in all languages, based
on the mapping of terms between languages in the old values. Basically the
structure of the value must remain the same in all languages, like before.
Reading a translated field is now both simpler and faster than the former
implementation. We fetch the value of the field in the current language by
coalescing its value with the 'en_US' value of the field:
SELECT id, COALESCE(name->>'fr_FR', name->>'en_US') AS name ...
The raw cache of the field contains either None or a dict which is conceptually
a subset of the JSON value in database (except for missing languages). For the
sake of simplicity, most cache operations deal with the dict and return the text
value in the current language.
Trigram indexes have been adapted to the new storing strategy, and should enable
to search in any language. Before this change, only the source value of the
field ('en_US') could be indexed.
Computed stored translated fields are not supported by the framework, because of
the complexity of the computation itself: the field would need to be computed in
all active languages. We chose to not provide any hook to compute a field in
all languages at once, and the framework always invokes a compute method once to
recompute it.
Code translations are no longer stored into the database. They become static,
and are extracted from the PO files when needed. The worker simply uses a cache
with extracted code translations for performance. This is reasonable, since
fr_FR code translations for all modules takes around 2MB of memory, and the
cache can be shared among all registries in the worker. Changing code
translations requires to update the corresponding PO file and reloading the
worker(s).
Performance summary:
(+) reading 'model' translated fields is faster
(+) reading 'model_terms' translated fields is much faster (no need to inject
translations into the source value)
(+) searching translated fields with operator 'ilike' is much faster when the
field is indexed with 'trigram'
(+) updating translated fields requires less ORM flushing
(-) importing translations from PO files is 2x slower
Some extra fixes:
- make field 'name' of ir.actions.actions translated; because of the PG
inheritance, this is necessary to make the column definition consistent in
all models that inherit from ir.actions.actions.
- add some backend API for the web/website client for editing translations
- move methods get_field_string() to model ir.model.fields
- move _load_module_terms to model ir.module.module
- adapt tests in test_impex, test_new_api
- because env.lang is injected into SQL queries, its returned value is
now guaranteed to correspond to a valid active language or None
- remove wizard to insert missing translations (no longer makes sense)
task-id: 2081307
Co-authored-by: Fabien Pinckaers <fp@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
This change allows for adding and removing followers from threads
by directly setting the message_partner_ids field of threads.
This enables the use of many2many_tags to add followers to a thread.
Task-2804888
closesodoo/odoo#95645
Related: odoo/enterprise#29284
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
XML files are now declared in python module manifests. During the qweb
't-call-asset' directive, assetbundle will fetch the declared xml files,
apply the inheritance (t-inherit) and create a javascript service (for
eg: 'web.assets_backend.bundle.xml') which is added at the end of the
*.js mimifier file.
When the debug mode is activated, comments are added in the template
indicating which file the template comes from as well as the
inheritances applied to it.
****
JavaScript:
assets.js (module @web/core/assets) takes care of loading libraries,
javascripts and styles.
`loadJS(url)` (loads the javascript and returns a resolved promise when
the templates are also loaded via the '*.bundle.xml' service)
`loadCSS(url)` (loads the style a resolved promise when the file is
loaded)
`loadXML(xml, app=assets.defaultApp)` (load template into
application/owl, used by the `*.bundle.xml` services)
`getBundle(bundleName)` (get the bundle descriptor)
`loadBundle(desc)` (load the files and bundle from a descriptor)
templates (XML element content all owl templates)
A new `ready(serviceName)` method on boot.js lets you know when a
service is loaded are the require.
The xmlDependencies attribute no longer exists.
Python:
The xmls taken into account by assetbundle.py, applying `t-inherit`
inheritances and adding an `name_of_the_bundle.bundle.xml` service in
the generated JavaScript file.
****
Every manifest changes is into the next commit, except 'web_tour' in
this current commit as example.
Part-of: odoo/odoo#95500
Make mail_notification_layout as the default mail template and remove
message_notification_email. We now only have 2 main notification mail layout
templates (outside of a light one): the default one and one that inherits from
it to only change the signature to the responsible instead of the author one.
In this operation the layout of message_notification_email has been integrated
in mail_notification_layout to support outlook mail client for which
message_notification_email has just been reworked (odoo/odoo#92847).
Technical note: we have integrated the "internal communication" banner from
"message_notification_email" into the new default template
"mail_notification_layout" which cause one added query in the test for querying
the flag internal from mail.message.subtype.
Task-2801600
Part-of: odoo/odoo#88466
Ease the understanding of the notifications sent when users are assigned to an
activity or a model (task, lead, ...).
Technical note:
- the customization of data sent to the email layout template (here subtitles)
should be done by overriding
mail_thread._notify_by_email_prepare_rendering_context on the model.
But in this case, we send an activity (ex.: todo) for a model (ex.: crm.lead)
which involves 2 models. Data from both models must be sent to the template
layout. To solve this problem an optional parameter to
mail_thread.message_notify has been added: subtitles. This allows the
caller which knows about the 2 models to set the values for subtitles for
the template.
- mail_activity._render_notify_header has been added to render the subject and
subtitles using the language of the recipients through the context lang
variable.
- a generic mail notification template has been added and the specific
mail_notification_paynow has been derived from it as the only change is the
handling of the signature.
Task-2801600
Part-of: odoo/odoo#88466
The main goal is to reduce the number of KB sent by the `get_views`
method to the web client by getting rid of things not used by the web
client.
This revision aims to only pass the `fields_get` info of fields
actually required by the web client.
Before this revision, for each view, the list of all fields
of all models implied in the view are passed.
For the main view, it's required to pass all the fields,
for the search view: The advanced search needs to know all fields
of the model to be able to let the user to do advanced filters and
groupbys on the model fields.
But, for the models of the subviews (one2many/many2many embbeded views),
this is not required. Only the fields included in the view are required.
Also, if the search view is not requested by the web client,
then it's also not required to pass all the fields of the main model.
After this revision, for each view, pass the `fields_get`
info of only the fields actually implied in the view.
For the search view, info of all fields are passed,
not only the ones implied in the view.
For instance, on the `get_views` of `account.move`,
this allows a gain of an extra 18,05KB,
reducing from 165.82 to 147.77KB.
In addition, before this revision, the whole content of `fields_get`
was stored in the cache of `_get_view_cache`, meaning per view.
If 3 views were requested on `get_views`
let's say kanban, list, form,
the same whole `fields_get` info, of all fields,
was stored 3 times in the cache.
This revision removes the content of fields_get of the cache
for `get_views`, to avoid storing multiple times the exact same
information in the cache, therefore gaining tremendous memory,
while not loosing that processing time.
The decrease of speed is only 1~3ms per call to `get_views`.
This is mainly because all the information gathered by `fields_get`
is already in the cache. For instance, it doesn't require any SQL
request (at the moment). e.g. the translations (string, help, selection)
are already cached.
closesodoo/odoo#99834
Related: odoo/enterprise#31167
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
An explicit access check when posting a message has been added at odoo/odoo@9920f20e4c
when adding notably computation of display_name as sudo. However this is not
the role of ``message_post`` to check access for such an implementation
details.
Access is anyway already granted through the various browse and record access
done during the posting process. Moreover even message access (creation or
read) is protected notably through its related record ACLs.
Portal/Public access on message_post is anyway done through dedicated routes
using tokens or hash/pid that call message_post as sudo. We can therefore
remove the explicit access check added a bit wildly in the middle of the code.
Task-2710804 (Mail: Clean MailThread API)
closesodoo/odoo#99654
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When creating records with default keys in context those are currently
propagated through the whole call chain until message creation. However
default keys are meant to be used for the record creation, not its logs
or messages.
A protection against default_child_ids already exists. However better
remove all context keys by using a clean context.
Closesodoo/odoo#93797closesodoo/odoo#99670
X-original-commit: 421ee12a099220cb43f3c3f0bf8d51586e687a28
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Returning after first loop iteration has the sad side effect of
somehow breaking batch version of methods.
Oversight of odoo/odoo@0ea27f430cclosesodoo/odoo#99630
X-original-commit: 6d6dbe16d4570372fe5fd3d28ebe5c43b646d3bc
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This PR fix a traceback that occure when the message body is empty (eg: only
uploading an attachment).
closesodoo/odoo#99625
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*: im_livechat, website_livechat
Access right should be based on channel type and membership instead.
Chat always private, group always private, channel private should
disapear and be a group instead (migration needed), and other channel
always public (but they can still be further restricted with
the "allowed groups" feature)
task-2632861
closesodoo/odoo#90415
Related: odoo/enterprise#30980
Related: odoo/upgrade#3850
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Vincent Schippefilt