Bug
===
If we re-write the same definition record, the default values were
applied again (even if the definition record didn't change).
This is because the compute on the properties is called even if the
definition record didn't change.
Task-2965523
X-original-commit: 70d80771f2430f83c91e7ef46eeebde8de70c3fe
Part-of: odoo/odoo#101487
Bug
===
- create a new helpdesk ticket without properties
- create a new property
- change the customer
=> The added property is removed
The fix in the onchange of models.py needs to be more specific, and
should be used only when the definition record is changed.
Task-2965523
X-original-commit: 909ee004183068d9ffa94abe0d1472a8f0534f34
Part-of: odoo/odoo#101487
Purpose
=======
Remove the code redundacy between
convert_to_column and convert_to_cache.
Task-2965523
X-original-commit: bbd307d7939319393e3b1782c7200f0010c8c018
Part-of: odoo/odoo#101487
Purpose
=======
Log a message each time a user change a properties definition
by writing on the record properties values.
Task-2965523
X-original-commit: 6fa6fcd13e248d4bdf1febb0d8399cfe634037f5
Part-of: odoo/odoo#101487
Purpose
=======
Improve the behavior / visual of the properties field when the user does
not have access to some relational properties (many2many, many2one).
When the user does not have access to one many2many value,
show the others record in the list.
Fix a traceback when the model is not set on the definition.
Task-2965523
X-original-commit: cb8b751a335b01192aab185cd0230fa0f036b974
Part-of: odoo/odoo#101487
Purpose
=======
Shorten the property name to take less space in database (while keeping
a very low probability of collision).
E.G.: "aa34746a6851ee4ea1f8d95746e45788" -> "aa34746a6851ee4e"
Automatically generate property name in python if they are missing.
Task-2965523
X-original-commit: d597083ff5e0a4abde67a450a61e04e6bf119c26
Part-of: odoo/odoo#101487
Purpose
=======
Most of the time we will need to read some field on the definition
record when we read the record itself (e.g. fetching some project
information on a task).
Because of this, it makes sense to prefetch by default the properties
definition, and it reduces the number of queries as well.
Task-2965523
X-original-commit: 1295e76f0dc3f3162a1b81a58ed1dc73d0fce3e7
Part-of: odoo/odoo#101487
This commit does multiple things:
- The readonly mode of form view is removed but not for the fields.
it means that the fields in the view are always in edit mode except
if we force them to be readonly.
- The control panel is revamped to take less vertical space and shows now
the record editing (dirtiness)/validity status after editing the record.
- The record is saved only when leaving the view or by clicking the save
button when hovering the record status in the control panel.
- The record can still be discarded by clicking the discard button when
hovering the status text in control panel.
task id: 2822553
X-original-commit: 77824ad44b6945a9811120380747f87ef6362ae2
Part-of: odoo/odoo#101118
Co-authored-by: luvi <luvi@odoo.com>
This commit introduces the new calendar view written in owl.
closesodoo/odoo#101185
X-original-commit: e88988f58582d5b49a32d7102a74a176f40c4c69
Related: odoo/enterprise#31808
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
This commit extract translatable content from spreadsheet data.
- chart titles and description
- pivot and list names
- argument of _t() functions
- labels of links
X-original-commit: d210a55f48b316fdf38fcbe5ae5a70cf0e2c3814
Part-of: odoo/odoo#101120
Purpose
=======
The template user groups are applied to new users, but this is not the
case for existing users.
To harmonize the flow, the added groups to the default user template are
synchronized with the existing users.
closesodoo/odoo#101086
X-original-commit: aefb05eb497a8a16a9359432f41024c09552ed70
Related: odoo/enterprise#31759
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
If called in cascade, this could lead to a situation in which a same
thread is trying to create recursively several registries when loading
the sames modules, which obviously cannot work in any way.
Use button_install instead, that will simply update the module state
while waiting to be installed in a proper way, instead of forcing
a registry creation that will mess the whole process.
X-original-commit: 6b52844a8dc78788cbd948c7e2f90156ee8b89d7
Part-of: odoo/odoo#101086
Given the group only contains EU27 members and the UK was specifically removed in 52cdfd22d7 it seems clear this group represents the European Union speifically rather than any other interpretation of "Europe".
Rename the group to match.
closesodoo/odoo#101051
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The cache currectly fails to correctly invalidate relational fields that depend
on a non-relational field. Two passes of invalidation are done, to reflect
dependencies on both the old and the new written values. In the first pass
only relational fields are considered, as explained in the comments:
> It is best explained with a simple example: consider two sales orders SO1 and
SO2. The computed total amount on sales orders indirectly depends on the
many2one field 'order_id' linking lines to their sales order. Now consider the
following code:
>
> line = so1.line_ids[0] # pick a line from SO1
> line.order_id = so2 # move the line to SO2
>
> In this situation, the total amount must be recomputed on *both* sales order:
the line's order before the modification, and the line's order after the
modification.
The written values can be seen as the roots of a dependency forest (a
collection of dependency trees). Before this commit all non-relational roots
and their corresponding trees were filtered out during the first pass. However,
this approach is wrong, as relational fields can also depend on non-relational
fields. Instead, the complete dependency forest has to be traversed, skipping
invalidation for non-relational fields during the first pass.
The test that was previously included accidentally succeeded because of a
separate and unrelated bug in the orm domain parser: in certain one2many or
many2many leafs the domain parser would not take into consideration the domain
included in the definition of the field. As a result, the test still passed
by accident, because the records that no longer matched the domain after the
write were still invalidated during the second pass.
The problem can clearly be demonstrated, however, when the dependency is
generated by a compute function.
closesodoo/odoo#101038
X-original-commit: d4a5827b42d80f0f830455dcd2056701eb09aed1
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Nodes like
<attribute name="t-on-dragenter.stop.prevent">() => state.dropzoneVisible = true</attribute>
should not be exported in the translations files but
<attribute name="string">Hello World</attribute>
should be kept
It was already the case in the xml processing method for server side
templates.
Since 16.0, client side QWeb views also use the same inheritance
mechanism than the one on the server side so the exception needs to be
replicated.
X-original-commit: e05d1192481935b2cd7aae7e939f98e60e002899
Part-of: odoo/odoo#101053
- In `unlink`, since https://github.com/odoo/odoo/pull/66938
modified is called on self for each batch of 1_000.
But it should be called on the batched records.
- In `write`, remove useless `records_to_inverse`
(there from ORM refactor but never used)
- make `_modified_triggers` more deterministic by
changing a `set` into `OrderedSet`.
closesodoo/odoo#100472
Signed-off-by: Raphael Collet <rco@odoo.com>
So far the vat_label was missing in res_country_data.xml.
This defines the official name for the local Tax ID (called "RUC").
closesodoo/odoo#100650
X-original-commit: 53b0ff01535c10d31102e9087d9e5196fa261630
Signed-off-by: Laurent Smet <las@odoo.com>
Longpolling port is replaced with gevent port and is deprecated
This commit avoid saving the value.
Not really usefull but when saved the value was None leadind to an error
when casting to int. The default value should be an int.
closesodoo/odoo#100991
X-original-commit: adac9a9ceaa173c0181a4fc57d0ea83b7a37fc71
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Indonesia officially added new province. Papua Selatan, Papua Tengah, Papua Pegunungan.
closesodoo/odoo#100980
X-original-commit: 9d047bfac876f814f46cf212d2be44614a8e7a71
Signed-off-by: Jérémy Kersten <jke@odoo.com>
This commit avoid to have a dict by reference that will be global.
Now get_default_session return a new dict each time for the context key.
From this way the session.context['lang'] is not shared between several
users on the same worker.
To reproduce the bug, restart the server with 2 workers, make request in
lang A on these 2 workers. DEFAULT_SESSION['context']['lang'] now is set
to this lang A.
Now, make request to an url without lang in path and without cookies and
withtout session, you should be redirected to lang B (preferred lang
from the request header) but you will be redirect to lang A due to the
dict session.context that is shared for the worker...
When we initialize the new Session, we get the wrong lang A as value for
context.lang, so we don't recompute the expected lang for the end user.
X-original-commit: 62179de74862210fe2a055d15b367b1850c24263
fwd-port of #100102closesodoo/odoo#100910
X-original-commit: 42e46b2d89dde276f796b980f29e33cc216e7cb2
Signed-off-by: Jérémy Kersten <jke@odoo.com>
The purpose of the task is twofold:
1. Remove empty lines in the company address.
Until now, the address format was fixed, which could
lead to empty lines if one or more field(s) were missing.
We are now removing empty fields to avoid that.
2. Make sure the external report layout is configured
before generating the PDF.
This will ensure that the company data will appear
in the file. If no layout is defined,
it would not be shown.
task-2834517
closesodoo/odoo#100936
X-original-commit: f36bb6acdacaaba26afdd8f62c48fd2c8784d1e1
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Since this commit, https://github.com/odoo/odoo/commit/32ada4a415a14052d780f351edb82a0011561451,
when adding a new rate from the tree view,
if the `name` field is emptied (despite having a default value),
the `_onchange_rate_warning()` method will generate a traceback
because it will call `_get_latest_rate()` that relies on the `name`
field to order the company rates.
Steps to reproduce:
- Go to the Accounting App.
- Click on Configuration > Currencies.
- Select any currency and click on "Add a line" in the Rates tab.
- Remove the default value from the "Date" field and leave it empty.
- Now try to change "Unit per USD". A traceback should be triggered.
New behavior:
With this fix, an error message will now invite the user to set the `name`
(a.k.a. 'Date') correctly.
closesodoo/odoo#100874
X-original-commit: ddced61ca27f96b89af32f0b99e225321f966681
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Bank statements are now optional in accounting. The users add statements directly and can assign statements for control reasons.
The users can enter end date and end balance real for the statements and attach the bank statement scan.
The system checks if there is a gap (lines without statement) before current statement and warns the user
with decoration, also we check if the ending balance match the accumulated balance of the last line.
Bank statement lines now show an accumulated balance and can be sorted by drag and drop in the same date, if the user drags a line
to a position with lines of another date, it simply doesn't have any effect.
Rename accumulated balance to cumulative balance, a better name
closesodoo/odoo#99092
Task: 2879904
Related: odoo/upgrade#3906
Related: odoo/enterprise#30824
Signed-off-by: Laurent Smet <las@odoo.com>
Due to group inheritance mechanism, if we try to "downgrade" the group
on a user's form view, after saving the record, sometimes the changes
may be reset automatically. Same kind of confusing behavior appears when
groups are automatically added due to cross-apps access rights dependencies.
This is very confusing because users can not easily understand what is
happening and why.
This commit improves the behavior by providing a proper warning string
to user on the fly when the groups are changed (which can potentially
be reset upon saving). For better understanding of possible scenarios
and the warning linked with them, see the test-cases that explain
everything with visual hierarchy.
taskID-2646704
closesodoo/odoo#91641
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
A feature allows to set the modifiers invisible, readonly, required
according to a key in the context
e.g.
```xml
<field name="date_approve" invisible="context.get('quotation_only', False)" optional="show"/>
```
Following odoo/odoo#99417,
back-end views are now cached.
These expressions are currently evaluated server-side,
before serving the view to the web client.
Hence, the modifier becomes for instance `invisible="1"` or `invisible="0"`
according to the context passed when calling `get_view`.
The key used to cache the views doesn't take into account such context keys.
Hence, when you asked for a view using for instance
`invisible="context.get('quotation_only')"`
A first time using the context `{'quotation_only': True}`
and a second time using the context `{'quotation_only': False}`,
on the second time, you received the view from the first time you
requested the view, where the modifier is evaluated as if the the
context was `{'quotation_only': True}`.
As we do not want to store a cached version of the view for each
possible key in the context, postprocess the evaluation of the
modifiers using the context after retrieving the view from the cache.
A better alternative would be to delegate this evaluation to the
web client, because it already has the information it needs,
it has the context value.
Modifiers using domains are already evaluated client-side,
it would make sense modifiers using context would too.
Nevertheless, as this bug has been introduced by odoo/odoo#99417,
and as we are close to the release, solve this server-side,
to keep a similar behavior than before.
We might re-consider the implementation of this later on.
closesodoo/odoo#100130
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
The tour test_01_admin_widget_x2many was failing because of a missing
discussion. This discussion was in fact coming from a patch
during at install tests
This wasn't detected on runbot during merge since at_install and
post_install are executed in different builds. This was detected
during the nightly "all no auto tag" build.
Simply use a proper patch to avoid keeping the default value at the
end of the test.
closesodoo/odoo#100491
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Oversight in odoo/odoo#100376
The web client sends `list` rather than `tree` when requesting
views.
However, once they went through `get_views`, they are converted back
to `tree`.
https://github.com/odoo/odoo/blob/master/odoo/models.py#L1653
So, here, we should check against `tree`, not `list`.
Could be seen in Lunch > Manager > Today's Order.
With the `id` field missing, an error is raised
```
Uncaught (in promise) Error: The following error occurred in onWillStart: "field is undefined"
```
closesodoo/odoo#100474
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Printing an invoice no longer saved the ir.attachment on the
move.
This is due to the refactor in ffc525419a,
since the render methods are now `api.model`, `self.attachment` was always
Falsy. To get the attachment name of a report, we need to call
`self._get_report(report_ref)`.
closesodoo/odoo#100363
Signed-off-by: Laurent Smet <las@odoo.com>
When a module extends model 'base', the database schemas of all models are
checked, including indexes. And a log message appears for "unexpected index
mail_message_subtype_id_index on table mail_message_subtype". The index indeed
exists, but not for the table mentioned in the message. The ORM actually makes
a confusion between:
- the index mail_message_subtype_id_index for subtype_id on table mail_message
- the index mail_message_subtype_id_index for id on table mail_message_subtype
The fix consists in logging the message about the unexpected index only if the
index is on the expected table.
closesodoo/odoo#100297
X-original-commit: fe8d0024897208e876f097564d50e6795df2c1d3
Signed-off-by: Raphael Collet <rco@odoo.com>
Currently the exception is not logged using the logger meaning that the
only indication of the failure is the "module not loaded" error message.
Catching the exception to log it the proper way will help identifying
the cause of the issue, mainly for uninstall tests.
closesodoo/odoo#100431
X-original-commit: b16f850d9aa438aea91b8cbd7c33692e1e1b2f90
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Following odoo/odoo@4636620004
`get_views` only pass the model fields included in the view architecture,
except for the main model when the search views is requested.
Because the search views requires all fields for the user to be able
to make advanced filters and advanced group by using any fields of the
model.
However, other views requires more field descriptions as well than
just the fields included in their architecture:
- the graph view requires all integer and float fields,
to automatically add suggestions of measures in the measures dropdown
menu. It's a bit like the search view, the user should be able
to choose any measure available in the model
(as long as this is integer or float fields)
- the pivot view requires all groupable fields,
so the user can group by any groupable fields of the model.
The JS MockServer `getViews` is adapted to include the changes added by the above
revision as well as the current revision,
for the qunit tests suite to be able to reflect these API changes
from the server side.
closesodoo/odoo#100376
Related: odoo/enterprise#31427
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
When sending a mass mailing with a pdf attachment, the ir.attachment
is copied in the mail.composer for each email. Spending time and
resources in the indexing of the pdf. On copy that value is already in
the vals. This is especially true when attachment_indexation is
installed, processing the pdf documents can be costly with pdfminer.
It could also be done by overwriting the copu from ir_attachment but it
could happen a misuse of mass create of ir.attachment with the same file
has the same issue
closesodoo/odoo#100374
X-original-commit: 3d59cc849ed1040c08c4d1488866ba78c80990c8
Signed-off-by: Raphael Collet <rco@odoo.com>
Since #99912 logging an error message doesn't always end qunit tests.
This was mainly to allow to failfast logging qunit errors earlier
without stopping the tests in order to test all qunit anyway.
The logic was to have an end message that stops the test.
Unfortunately some errors will prevent the qunit suite to start
and the test will wait a 1800 long timer. An example was because of
a Missing dependencies. https://runbot.odoo.com/runbot/build/19306352
This new approach will avoid to stop only if the message looks like a
qunit failure and the final message is not there (to be sure).
closesodoo/odoo#100238
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
[IMP] core: store translated fields as JSONB columns
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)
closesodoo/odoo#97692
Task-id: 2081307
Signed-off-by: Raphael Collet <rco@odoo.com>
The current asset_bundle version uses the last modified date.
This can be problematic in some case.
Even if it is a long time issue, the problem was rediscovered on runbot
with a commit being in the future. Runbot will export all file and set
the write date of the file to the commit date. The main purpose is to
have deterministic bundle version between different builds. This also
allows to generate assets bundle once at install for all post install
subbuild.
The issue here is that the commit date was greater than now(), meaning
that some tests setting custom css in attachment won't trigger the
regeneration of assets bundle. This wasn't really noticeable before
assets pregeneration.
This is not the first time strange issues occurs because of the
last modified logic.
This commit combined all last_modified to generate the bundle
version.
The current adaptation is quick and dirty and this will be reworked in
another post 16.0 freeze assets refactoring and cleanup.
closesodoo/odoo#100160
Signed-off-by: Xavier Dollé (xdo) <xdo@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.
Previously, 'Edit Translations' button is used to translate
the English field ir_ui_view.arch
A dialog for list view of all translations is opened
After this commit, a new 'EN' button is used to translate
the Engligsh field ir_ui_view.arch
A translation dialog (like other translatable fields) for all translations is opened
General idea of the implementation:
1. add the invisible ir_ui_view.arch_db field to the form view before ir_ui_view.arch
2. show the 'Lang' button in the edit mode
and make it look like a button for its next field ir_ui_view.arch
3. Forcely change the 'Lang' button to 'EN'
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>
The purpose of this PR is to inline the "Validate" button
with the `country_id` field on the partner form view
when using Avatax.
task-2947705
closesodoo/odoo#100093
Related: odoo/enterprise#31277
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
This commit changes the node modifiers domain evaluation in the Form test class to allow strings.
Domains as strings are used by the web client to evaluate special values such as 'uid'.
Part-of: odoo/odoo#99735
std-odoo