- discourage users from changing the currency's rounding precision by
making it editable only before the currency is saved;
- remove the hard-coded dict of minor units that util functions rely on.
task-3076355
closesodoo/odoo#119308
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
JSONDecoderError occurs when users enters invalid JSON format data in
'Default Value' field inside 'User-defined Defaults' and wherever this field is
being accessed to get default value this traceback will be generated.
Steps to reproduce:
1) Install 'Contacts' module.
2) Open 'Settings' > 'Technical' > 'User-defined Defaults'.
3) Click on record 'Language' > 'EDIT' button > in 'Default Value' field enter
any improper JSON format data (e.g 'Maa' : FI ) .
4) Now, open 'Contacts' module > click on 'CREATE' button and traceback would be
generated.
By applying this, it will check for proper JSON format.
Sentry-4169062951
closesodoo/odoo#126932
X-original-commit: 71b32d9ea892c8a79c8eac51b9f394c92c44f45d
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
In 15.4 (with a226bd983b94a11af9b9785b753634213141127f)
was introduced the from_filter on the system param
and mail servers that would determine which
mail server should be use to send emails out.
In 15.5 (with dbb62515bc1772a79d336e8c2fc0bd1653f1f7ca)
was implemented a fix to prevent the usage of the
archived mail servers.
An email that is going out using an archived outgoing
mail server will be blocked with a specific error msg.
However, when doing specific flows, the context
active_test would be propagate and the function,
doing the search of the mail server to use,
would take into consideration an archived mail server
(the best matching depending on the from_filter param
-- see _find_mail_server fonction).
In order to reproduce this bug, here is one of the way
to do so (on runbot, local needs to add the CLI SMTP
args):
1/ Install sale_management and crm (including contacts).
2/ Add an outgoing email server and archive it.
3/ Go through a contact to an opportunity,
4/ Convert the opportunity to a new quotation,
5/ Send it by email (should be in quotation sent state)
Email will be failed with an error msg
"Connection failed (outgoing mail server problem)".
On the technical > Emails:
The server "<OMS name>" cannot be used because it is archived.
opw-3349593
opw-3341324
closesodoo/odoo#127187
X-original-commit: 716d07b49597ca2583a8e6587f1f530cca5ee8a7
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
A TypeError is thrown when an AST node is passed to `literal_eval`
because a string is expected and the object has no len().
Check the type of the expression and make sure it's a string before
calling len() on it.
closesodoo/odoo#126874
X-original-commit: 28b5cbb33a99cdca00daa35e5ae598cc8d4b2dae
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
* = account{_payment}, base, onboarding, payment{_stripe},
sale{_management}, web, website_sale
Use the dedicated onboarding module introduced in 16.0 instead of
the res.company model to store onboarding progress.
It allows
* onboarding steps to be reused across panels
* to support steps that should be completed per-database or per-company
* to clean the res.company model from many fields and methods,
* to remove many views, controllers, actions
Module-specific notes:
* account: We also clean the remaining two steps that are not
part of an accounting panel but make the most sense to be kept here.
* account_payment: Following 8e4e8eb8, the payment provider step is
added to the invoicing onboarding panel. We apply this change here too.
Also impacts the website_sale_dashboard panel (see related ENT PR).
(The "sale tax" one is currently used for to the website sale dashboard).
* payment: Note that the step was already not part of an onboarding
panel within this module.
* website_sale: We clean
* a field not used (The website_sale dashboard onboarding panel used
the payment_provider_onboarding_state field).
* a method that was only called from website_sale_dashboard, so it is
moved there. See related ENT PR.
Includes a few tests.
Moving views/templates/styling, as well as cleaning residual onboarding-related fields and methods in base, including populate.
This also includes restoring the "onboarding_complete" overlay panel
animating it to disappear after a few seconds so that it doesn't hide
text and block buttons to re-open steps.
Task-3025136
Part-of: odoo/odoo#104223
When exiting a flushing savepoint, the method flush() is invoked before
closing the savepoint (which releases it):
def _close(self, rollback):
if not rollback:
self._cr.flush()
super()._close(rollback)
If method flush() crashes at that point, the savepoint is not closed at
all (because of the exception) and is therefore not even rolled back.
The expected behavior is that the savepoint rollbacks and the exception
bubbles up.
closesodoo/odoo#126866
X-original-commit: 5f9b4f5c998388625de27fbd8fe0f7a0524c04fd
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
If Automation Actions's configuration is done wrong it will
cause Error at runtime which will be caught in sentry and
causes unnecessary traffic.
So, we stop catching exceptions from Automated Actions.
sentry-4200700020
closesodoo/odoo#126658
X-original-commit: 3479d998417b60807c288c047a1f469329dee59c
Signed-off-by: Achraf Ben Azzouz (abz) <abz@odoo.com>
Purpose
=======
Some SMTP configuration can be used for many domains names. E.G.,
our own SMTP configuration can be used for both "mail.odoo.com" and
"odoo.com". So we want to be able to set a list of allowed domains
name, separated by a comma, instead of a single domain.
Task-3332488
closesodoo/odoo#122234
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The previous commit introduced an optimization to reduce the number of
queries and fields fetched when we call `name_search`. But it works much
better when the dependencies of `display_name` contain field names used
in the calculation (on the same record/model).
Then, to improve the performance and the cache coherency, add `depends`
and `depends_context` depending on the custom `_compute_display_name`.
Add only the first level of dependencies (never traverse relational
field) because only these have a positive impact on the previous
optimization and the cost is very low (see `modified`).
About `depends_context`, we don't include `lang` because (when `_` is
used by example) it is unlikely to get the same display_name in the same
request with two different lang.
closesodoo/odoo#122085
Related: odoo/documentation#4639
Related: odoo/enterprise#42599
Related: odoo/upgrade#4780
Signed-off-by: Raphael Collet <rco@odoo.com>
The `name_search` makes at least 2 SQL requests, one to find the records
and one to read fields needed to compute the `display_name`. With the
default `_compute_display_name`, it only needs to fetch the `_rec_name`
field (if there is one), but the ORM perfetch field mechanism will also
fetch every prefetchable field (see `_fetch_field`).
Then, to avoid running two queries and fetching too many fields, we add
the dependency fields (with `_determine_fields_to_fetch`) to the select
clause of the `Query` returned by `_name_search`.
Part-of: odoo/odoo#122085
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
This commit fixes the malformed comment that would sometimes comment out
the rest of the html resulting in an improper display.
this is due to the new html5 notation --!> not behing understood by
our parser.
this commit replaces any --!> into -->.
this commit also remove <!--> or <!--->
opw-2812488
closesodoo/odoo#126148
X-original-commit: 4fed0c36fedf271acc3520d8219763964753dabe
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Since stock.quant are directly related to their lot/serial, we want to be able to show the lot properties on the related quants.
We also want to be able to filter quants based on the properties of their lot/serial.
closesodoo/odoo#125197
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This error occurs when user import records having value in 'properties' column
which is of datatype, 'properties' and while trying to get attribute from
getattr to get value of converter it is getting default value None. That's why
this error is produced, 'NoneType' object is not callable.
Steps to reproduce:
1) Install 'CRM' module.
2) Open 'CRM' module and in it click on 'List' view.
3) Open any record and add value for field 'Add a property'.
4) Export that records.
5) Now click on 'Favourites' > 'Import records'.
6) Now click on 'UPLOAD FILE' button > upload that exported file.
7) Now click on 'TEST' button, error will be generated.
By applying this, user will be able to import record of datatype
'properties'.
Sentry-4128524668
closesodoo/odoo#126609
X-original-commit: b80d4294a000e748677a3a0c1849140bf46ddbe8
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Added few basic rules and folders that are usually common to most localizations.
The template will also serve as documentation on naming conventions (not strict atm).
closesodoo/odoo#121446
Usage: ./odoo_bin scaffold -t l10n_payroll name-code (e.g. estonia-ee) [destination]
Signed-off-by: Kevin Baptiste <kba@odoo.com>
After this commit, underscore library is totally removed.
Library calls has been removed from manifests.
Library files has been deleted.
This commit closed the task below.
task-3246238
closesodoo/odoo#125889
Related: odoo/design-themes#662
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Revision odoo/odoo@cabb9e7e57 introduced a
regression: This is no longer possible to import a data module
using `<field file="..."/>` in their data file.
This revision targets to restore the feature as expected.
The unit tests added covers the feature, so that regression
no longer happens in the future.
It introduces a new concept of temporary directory `file_open`
can read from.
e.g.
```py
with odoo.tools.file_open_temporary_directory(self.env) as module_dir:
with zipfile.ZipFile('foo.zip', "r") as z:
z.extract('foo/__manifest__.py', module_dir)
with odoo.tools.file_open('foo/__manifest__.py', env=self.env) as f:
manifest = f.read()
```
Note that `file_open` will be allowed to read from that temporary
directory only if `env` is passed to `file_open`,
and if the `env` is part of the same transaction/request than the `env`
passed to `file_open_temporary_directory`.
This is to avoid having users, whether from other databases,
or even the same database,
trying to access these directories not belonging to them.
e.g. If an admin uploads sensitive data in this temporary directory,
no one than him must be allowed to read from these files, not even
another user from his database.
closesodoo/odoo#126326
X-original-commit: ea5cfe2e9493e4ef5a9b81851af452c8c51e407e
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This commit moves and adapt the res.users.settings model from mail to base and
and allows to access and modify its content with web's user service.
This allows to access user settings without needing the mail module.
closesodoo/odoo#116005
Related: odoo/enterprise#38360
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
When user deletes 'Portal User Template' record from 'res.users' model and when
'action_open_template_user' function is executed at that time traceback is
generated on the user side as well as in the log.
Steps to reproduce:
1. Install Website module.
2. Go to settings > Users&Companies > Users.
3. Remove Internal Users from default filter.
4. Add Inactive Users in filter and delete Portal User Template.
5. Go to Website Settings > Privacy > Customer Account.
6. Click on Free sign up and then on Save button.
7. Now in Website Settings click on Default Access Rights button.
8. The error will occur.
Applying this commit will fix this issue.
sentry-4184456381
closesodoo/odoo#125761
X-original-commit: f1906f4bb21a88e0c8008393557a16b098dea3c2
Signed-off-by: Rémy Voet <ryv@odoo.com>
Identifiers (including column names) that are not double-quoted are folded to
lowercase in PostgreSQL. Before this commit, this resulted in errors when
updating translations for translatable fields, because the query did not
correctly quote all identifiers.
opw-3287428
closesodoo/odoo#125641
X-original-commit: 70ae8de223fc10f6e80dae06b0f6a6f15c198b5f
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Tom De Caluwé (tdc) <tdc@odoo.com>
*: account, crm, crm_iap_mine, event, hr_expense, hr_holidays,
hr_recruitment, lunch, mail, mass_mailing, point_of_sale, project,
purchase, purchase_stock, sale, survey, web, website, website_blog,
website_event, website_forum, website_sale, website_slides,
test_main_flows
In odoo/odoo#111103 the tour system was rewritten. The previous tour
system used to depend on the `root.widget` js module, and this module
was an async module that indirectly depended on `session_bind` which
would load the translations, meaning that the js module definition code
of the tours would only run after the translations were loaded. This is
no longer the case with the new tour system, this means that the module
definition code is executed as soon as the dependencies of that module
are fulfilled, which is generally befoe the translations are loaded,
causing most tour tips to not be translated.
This commit adds a hacky workaround for this problem: it creates a new
module that has a default export which is a promise, and has a legacy
alias, this creates an async module that waits for the translations to
be loaded. This module is then imported for its side-effect in all
onboarding tours, causing them to be translated correctly once again.
This commit also needs to convert the steps key in the tours internal
registry to a getter. In previous versions, the steps were directly
added as is to the internal state of the tour service, but since
odoo/odoo#122834 the steps are now mapped, and without a getter, any
edits to the steps occurring after registration will not be taken into
account. This causes issues in some modules that change original
behaviour of other modules (eg accounting makes invoices into a menu in
the accounting app instead of a top-level app in the home menu) as they
need to edit the steps of existing tours to make them work.
In a separate PR, we will implement a more proper fix by changing the
API of the tour manager so that we no longer need this workaround.
closesodoo/odoo#125284
X-original-commit: d130699ba82dc9919c9116f4b64a5e461ebb6319
Related: odoo/enterprise#42655
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Before this commit, it was not possible to create a custom monetary
field without having currencies named `currency_id` or `x_currency_id`
in the model.
With this commit, we store the currency_field from the Monetary field
in the database. This allows to create custom monetary field with
currencies name we want.
A good use case for this IMP is for Studio, we can now create and edit
monetary field easily without storing it as a `float` in the ORM.
Part-of: odoo/odoo#118199
The Gevent worker has specifc needs in term of maximum concurrent
connections to the database and those needs are not compatible with the
default limit that is primerly set for http workers.
This PR makes it possible to supply a configuration dedicated to the
gevent worker.
task-id-3193565
task-id-2146565
closesodoo/odoo#125190
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
This commit introduced a way to log queried table on cursor without
having to be in `--log-sql` mode.
It will be used in next commit to add complete performances tests which
will ensure the correct tables are accessed when a page is requested.
This is useful as right now those performances tests are only doing a
check against the SQL query number without ensuring the queries are the
correct ones.
As a result, one could introduce an improvement which would reduce the
queries (-2) but break another previous improvement (-2) which would
add back those queries (+2). Since the query count would be the same
(-2+2), it would be undetected, instead of being fixed directly and
keep both improvements (-2-2).
See next commit for concrete example(s) and use of this improvement.
X-original-commit: 8ef6137a34aa35182399a2bd4b20dd57479ab2e7
Part-of: odoo/odoo#124939
Before this commit, a multiline SQL Query (crafted, as the ORM is one
lining the queries) would not be catched in the `sql_from_log` and
`sql_into_log` variables, despite being shown and counted in the request
queries (unless the `into` or `from` part of the query is on the first
line).
At the end, not only the query was not listed in this table report but
if you sum the table report queries, it would not match the shown query
count.
This is the case for the `website_visitor` UPSERT query:
```sql
WITH visitor AS (
INSERT INTO website_visitor (...)
VALUES (
..., (
SELECT id FROM res_country WHERE code = NULL
)
)
ON CONFLICT (access_token)
DO UPDATE SET
...
RETURNING ...
)
SELECT id, upsert from visitor;
```
This commit is allowing the `into` and `from` part of the select to be
detected even if it's not part of the very first line of the query.
As a result, since a SELECT and an INSERT could be part of a same query,
we exclude the SELECT to be considered as a SELECT query if an INSERT
was already found in this query.
This will allow to have table query count log be in par with the query
count number (except for the `base_registry_signaling`, see note below).
It will also be helpful in next commits which will introduce a way to
access those logged queried table in the testing suite without being in
`--log-sql` mode.
Note: the SQL query on `base_registry_signaling` (which occurs every
time to check if the cache should be invalidated) is not tracked
either due to how it is build, it doesn't seems really needed to
have this one shown in the table logs. See [1].
This commit also remove the `lower()` usage and use the `IGNORECASE`
flag from `RE` instead.
[1]: https://github.com/odoo/odoo/commit/4aeba0c12e0512e537178e6cba0993a11f001ec3
X-original-commit: 255aa168bef5d63480e88b4d34511e3aac910f49
Part-of: odoo/odoo#124939
This PR allows a line chart in cumulative mode to start at some
non zero value if some conditions are met.
For this, the attribute "cumulated_start" should be set to true on
the arch root node of the graph view. If set to true, if the first
groupby (if any) is a date/datetime field "d", and if the domain
contains a condition based on "d" - thus possibly excluding some
groups with "d" values inferior to the least "d" value found in
the fetched groups - the initial value for the cumulative chart
will be set to be the aggregated value for those excluded groups.
closesodoo/odoo#122321
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
The LINK command must include the corresponding record data in the
web_read() format instead of the diff() format. The real difference
shows up in x2many fields: web_read() returns them as lists of dicts (or
list of ids), while diff() returns them as lists of commands.
Part-of: odoo/odoo#124612
onchange2() reads the origin record from database, and copies its field
values in cache on the corresponding new records. The copied x2many
fields must use NewId instead of their real id.
Part-of: odoo/odoo#124612
When doing an onchange on some existing record, the x2many commands must
be applied on the current x2many value of the record. When doing an
onchange on a new record, the x2many commands must be applied on empty
x2many values.
Part-of: odoo/odoo#124612
Before this commit:
`id` cannot be set as the dependency for a field's compute method.
So, when a user configures `id` as a dependency for a studio field's compute,
there is no error shown to the user and
the field is saved with `id` as a dependency.
After this commit:
It will throw a `UserError` to the user.
sentry-3979435039
closesodoo/odoo#124660
X-original-commit: 9eab433e09aafafd3015f731b9ec449965d97748
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
THese are rarely intended for all users but often intended only for
employees.
account:
account.incoterms: only used within internal business models
account.journal.group: same as account.journal, add sudo in computed field
account_edi: need access to accounting objects
base_address_extended:
res.city: only employees should access address data
board: only employees uses this (old) module
crm:
crm.stage: internal users business object
hr_recruitment: employees can read
im_livechat: apply same as for the steps
l10n_ar: used on partner, not only invoices
l10n_ec: accessed only through account.move
l10n_latam: accessed on res.partner
mail:
publisher.warrenty.contract: no data, only static models
mail.channel: group_user has already his own rule
mail.group: group_user has already his own rule
mail.message.subtype: group_user has already his own rule
mail.message.all: remove, already has a portal and employee rule
partner_autocomplete: no interaction with public
project:
project.tags: only needed for project sharing
sale_management:
sale.order.option: same as sale.order
utm: employee already has write access
web_editor: test models that have nothing to do here
web_tour: only employees uses tours
website_sale:
product.ribbon: add sudo for access
base:
ir.default: only employees uses set (could probably be converted to group_system)
ir.ui.view.custom: same as ir.ui.view, add sudo when needed
report.*: portal users don't configure reports
res.users.log: create in sudo, no access needed (adapt test to use another model)
res.lang: still needed for public
closesodoo/odoo#118701
Related: odoo/enterprise#41285
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When user tries to import a module which does not consist of an icon and then
when user tries to access that module the error occurs.
Steps to reproduce:
1. Install web_studio.
2. Import a module(without icon) from apps > import module menu.
3. Now search that module in apps and click on module info.
4. The error will occur.
Applying this commit will fix this issue.
sentry-4206999375
closesodoo/odoo#124540
X-original-commit: 4b0221800ab75d5573e7066bf8beee14488062dd
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Send a request to any json-rpc route with a HTTP header
`Content-Type: application/json-rpc` but send non-json or
non-jsonrpc data in the body. The application crashes with
a 500 Internal Server Error instead of a 400 Bad Request one
closes odoo/odoo#124571
Closes: #122048
X-original-commit: a1b83b07996f3fe4744474ff4023a3a2ce17ac7f
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
This is a proposal to try to find a similar asset before generating one.
If get_attachments fails, the next step will be to generate the
attachments from scratch, a slow operations.
When creating a new website, all assetsbundle would actually be
similar to their version without website, but the url is different.
This can be visible because the first loading of /web is slow after
creating a new website: the website_id is forced in the session
and the assets_backend are regnerated, identical to the original ones.
This commit proposes to try to find an attachments with differents extra
but the same uniquifier when possible and copy it's content.
Note that just returning the other attachement url may work, but it
would be confusing to randomly have links to assets comming from another
website_id. This would also be a problem if the original attachment is
unlinked, forcing to recompute it for other websites.
Good to know, since the content is the same, no duplication of the
content should appear in the filestore, just an entry in the database.
Part-of: odoo/odoo#121376
1. move cache to _get_asset_paths
The `_get_asset_content` cache has many cache key that are related to a
posprocessing of the `_get_asset_paths` result, the heavy part of this
method. Moving the cache to _get_asset_content will have the benefit
to create less duplicates entries in the ormcache as well as less cache
miss.
To simplify even further, the css and js parameters are removed since
they only filter the output of get_paths, the heavy part of globing the
file will be done before that. Anyway, they are both true when called
from _get_asset_content, and the only other call, in
`_get_related_bundle` don't really need to filter them since it is not
a critical part regarding performance, and the funtional result will
stay the same.
The initial orm cache key was using `_get_template_cache_keys`, a little
overkill and possibly creating duplicates entries again. The only
context key needed is website_id for `_get_related_assets`.
Note that it is not really enough, the orm cache key should actually
contain `request.session.get('force_website_id')` as well has
`request.httprequest.host`. This will be addressed latter since a nicer
solution would be to have website_id as a unique parameter computed
earlier.
2. better _get_asset_paths cache key
The orm cache key was simplified in previous point but there is still
one concern, the website_id depends on more parameters than that:
- request.session.get('force_website_id')
- request.httprequest.host
- existing websites
The idea here is to call `get_current_website` instead of using all
parameters that could define the webiste.
In the same spirit of `_get_template_cache_keys` `_assets_path_params`
can be overriden to give extra params that are usefull to list assets
path. Those params are computed before entering the method
`_get_asset_paths`. This may latter put at a higher level latter, in
get_asset_node, to simplify the _generate_asset_nodes_cache key.
3. better assets_node caches key
The main purpose of this part is to improve ormcache containing assets
nodes. The ormcache key contains
- to much context key
- missing session/host/env info
- unwanted boolean options.
- keys leading to the same cache value
The main goal being to reduce the size of the cache keys, decrease the
number of cache entries and improve the cache hit.
This will also make the behaviour more coherent and hopefully less bug
prone because of mismatch in parameters.
The main reason of the orm cache is the slowness of the validation of
the assets. This includes:
- listing files (dedicated orm cache)
- computing version
The cache key was depending on
- `debug`
The only relevant value for debug is "contains assets"
We dont need to differ between debug='', debug='1', debug='test',
and 'debug=assets', 'debug=tests,assets', ...
- `defer_load`, `lazy_load`, `media`
Those values are only useful to generate html node, a leightweight
operations that does not really needs to be in cache. `media` was also
used in the generation but it looks useless if we have the media on the
node. THIS NEEDS TO BE VALIDATED but in any case, since media is not
used to generate the url, it doesn't make sence to use it in the
generation.
The main idea to remove them from the ormcache key is simply to generate
the nodes outide the ormcached values.
-`async_load`
This one is similar to `defer_load` and `lazy_load` but it looks like
it wasn't used anymore. This was simply removed
- context.get('lang')
The only information needed is the direction, rtl or ltr. This means
en and fr languages, despite sharing the same css assets, will duplicate
the ormcache entries.
-`_get_template_cache_keys`
Only the lang and webiste where really relevant in this flow. Other
keys are actually useless in this flow.
Some information used in the generation where not in the orm cache key
- `self.env.user.lang` if there is no lang in the context
- `request.session.get('force_website_id')`
- `request.httprequest.host`
- ...
The proposed solution is to:
- extract any informùation needed from thecontext, request, environment
before entering the ormcache, reduce it to the minimal possible set of
values needed
```
rtl = self.env['res.lang']._lang_get_direction(self.env.context.get('lang') or self.env.user.lang) == 'rtl'
assets_params = self.env['ir.asset']._get_assets_params() # website_id
debug_assets = debug and 'assets' in debug
```
and remove a leightweight part of the logic
```
def _get_asset_nodes(self, bundle, css=True, js=True, debug=False, defer_load=False, lazy_load=False, media=None):
links = self._get_asset_links(bundle, css=css, js=js, debug=debug)
return self._links_to_nodes(links, defer_load=defer_load, lazy_load=lazy_load, media=media)
```
Where _get_asset_links is the cached part, and _links_to_nodes is the
lightweight part generating the nodes based on the `defer_load`, ....
Additionnal notes:
- data-asset-version and data-asset-bundle are removed from the node
since they don't seem to be used anymore since 65d70acdbf
- async_load is removed since there is no occurence of this in the code.
- a small hack is still needed to pass javascript content instead of
links, this is only to manage css compile error and will hopefully be
removed in the future.
- a context key is still in use to generate the bundle, the
`commit_assetsbundle` but it has no impact on content and will hopefully
be removed in the future.
4. Add test for ormcache hit/miss
In this context, hit/miss is about having the same cache key for the
same result. This test demonstrates the current state, were entries are
create in the ormcache only if the key is really different and will lead
to a different result.
5. remove cache invalidation
This cache invalidation is quite agressive since everytime an
assetbundle is updated, all workers will clear their cache.
The concerned cache by this clear_cache is `_generate_asset_nodes_cache`
throug `_get_asset_nodes`.
The cache is ignored, both in dev=xml and debug=assets.
This clear cache was made conditionnal in 553ea82f81 but this does
not solve an issue we can have in production.
Lets imagine a clean solution
- all sources are updated
- all workers are restarted.
The orm caches are all empty, but since the sources
changed, all bundles will be recomputed. This means that every bundle
updated in database with save_attachement will invalidate the cache of
all workers. Rendering a pdf report of any kind using a specific bundle
will invalidate all cache. Starting a debug=assets for the first time
will invalidate all cache, even if the cache is not used in this case.
But for a regenerated bundle we would expect the ormcache to be:
- empty (did not generate the same bundle yet)
- have the same value (concurrent generation of the same bundle)
Having a different value would mean that the bundle was generated with
another version of the sources. In this case it is maybe even better not
to invalidate the cache since it could lead to an invalidation war
between two workers.
The only case where invalidating this cache is useful is when a bundle
changes, Usually if an ir_asset is created, modified, ...
There is still another rare but possible possibility to have a 404 if
the transaction is rollbacked after populating the assets node cache.
In this case, we only need to clear the cache locally in case of
rollback.
Part-of: odoo/odoo#121376
When user tries to quick create a field where model is not specified, the error
will occur.
Steps to reproduce:
1. Turn on developer mode.
2. Go to Settings > Technical > Fields Selection.
3. Create a new record and quick create a field.
Traceback will be generated.
Applying this commit will fix this issue.
sentry-3956146718
closesodoo/odoo#124442
X-original-commit: 9e64211eb4398b25c57d73bc5a92eda88d314bd1
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In Odoo editor when a html field is empty, we add en empty <br> inside the <p>.
This change broke all if statement checking that company details is empty.
In this commit, we add a function is_empty_company_details that return True if
the company details field contains only a <br> and False otherwise. With this
method, we can check that company details is empty and displaying other thing
that just an empty line break.
closesodoo/odoo#124440
Task-id: 3168705
X-original-commit: 2aaca9afb6c54be3ef87ea38646af90a2599aa6b
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
This commit includes the exception
details when logging an error in the registry module.
By importing the sys module and using the exc_info() method,
the commit ensures that the complete exception information is captured
by Sentry.
This modification improves the error reporting functionality
by providing more comprehensive information about the encountered
exceptions. This will aid in debugging and diagnosing issues,
enabling faster resolution of potential problems.
closesodoo/odoo#124318
X-original-commit: 55118b726bcd2532d2a7e67322eccb1ea6b75b7f
Signed-off-by: Achraf Ben Azzouz (abz) <abz@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
We have many issues with this log, except that with a `logger.error` we
do not have exception information (exc_info).
As mentionned in the documentation above, we cannot use `logger.exception`
in this case because we are not within an exception handler.
However, we can still retrieve the exception information using `sys`
module and the `exc_info()` method.
https://docs.python.org/3/library/logging.html#logging.Logger.exception
```
exception(msg, *args, **kwargs)
...
This method should only be called from an exception handler.
```
https://docs.python.org/3/library/sys.html#sys.exc_info
```
sys.exc_info()
This function returns the old-style representation of the handled exception.
...
If no exception is being handled anywhere on the stack, this function
return a tuple containing three None values.
...
```
closesodoo/odoo#124208
X-original-commit: b0844d2f3c0c9655746b4c16c9b612bae9954618
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
Valeriya(vchu)