An event was not called on uploading files in a media dialog.
This meant the parent of html field didn't know of the new attachments
which resulted in attachments being linked to no record at all
and not being garbage collected later.
This adds a reference inside the media dialog file input so that it can
trigger that event on behalf of the html field.
The attachments newly uploaded in media dialog are uneditable
to prevent users from unlinking attachments
that are still used in the body of the composer (causing the same issue)
Task-2860761
closesodoo/odoo#101405
X-original-commit: f4dd1eb3f25672e7309759c347e2b552c5652b2f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, if an invalid field was completed when editing
another field using an onchange, the field was always considered invalid.
It was not possible to save the record.
Why:
Fields modified by an onchange were not removed from the list of
invalid fields.
Solution:
Remove all fields modified by an onchange from the list of invalid fields.
How to reproduce:
- Create a new record in a form view with a required field
- Click on save (the required field appears as invalid)
- Edit another field that causes a change to the invalid field (onchange)
- Click on save
Before this commit:
The record is not saved and the required field is still invalid.
After this commit
The record is saved.
closesodoo/odoo#101343
X-original-commit: 46074244798d2e447f4e5cf174244ea263563b1d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Make it possible to override both before and after execute actions on
all view controllers using `useViewButtons`.
This avoids having to change a value in the env to override the function
being called when clicking on a button.
closesodoo/odoo#101310
X-original-commit: 9f6c2b8e969635f35786d58ee89ca767ff57144d
Related: odoo/enterprise#31860
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Before this commit, in a form view, discarding a record with an invalid
field containing an input does not restore the original value.
How to reproduce
- go to a form view with an integer field
- edit the integer field with an invalid value ("blabla")
- click outside the field (the field is displayed as invalid)
- click on the discard button
Before this commit:
The integer field always displays the invalid value.
After this commit:
The integer field displays the value before the edit.
closesodoo/odoo#101316
X-original-commit: f81e4019ca00953d9624557c98033aef46efc47a
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
If a view with groups and pager, going next then previous (back to the 0
offset) doesn't work.
The pager offset and limit were used in an conditional expression.
If the value was 0, it was considered falsy and set to a default value
while the 0 was actually a valid and expected value.
closesodoo/odoo#101314
X-original-commit: 5c9173241dbe55007c3a84fe078d21ea733e9046
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
When an action was retrieved from session storage, the no content helper
content was not markuped. It would therefore display hmtl text on the
user screen.
closesodoo/odoo#101306
X-original-commit: 592b8016b8a44dc1775918e4ffbf572e9b02c50f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
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 adds an option to many2one field to open the record either
in target new (dialog) or target current (replace view) which is now
the default.
task id: 2822553
X-original-commit: abe26f6eebb450512b35c25094329f85b98c15d9
Part-of: odoo/odoo#101118
This commit adds an option which allows getting the seconds in the
returned formatted hour.
task-2936932
X-original-commit: c7a3a40cadfe5f2db951860173417044e8e365c1
Part-of: odoo/odoo#101208
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 adapts codebase following the move and integration of the
touch device detection and customization (through the o_touch_device
class) in community.
X-original-commit: f3adc2b0f70feb80292f6c755d53690e49647dbb
Part-of: odoo/odoo#101185
Co-authored-by: Bruno Boi <boi@odoo.com>
This commit adapts codebase following the move and integration of the
touch device detection and customization (through the o_touch_device
class) in community.
X-original-commit: 5ae86ad473dd69559820b1f599ce389484cdebbc
Part-of: odoo/odoo#101185
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Before: On a map view, a bunch of points get loaded one by one. Each of
them triggering a new render of the controller. Currently, the useModel
hook does a deep render no matter what. If you are trying to set a
custom filter un the filter menu in the control panel, the content would
systematically diseapear (rerendered) when a new map point loaded.
After: To prevent this, setting the input node as t-model is a solution.
It allows owl to keep track of the value of the input and correctly
set it back when a render occurs.
closesodoo/odoo#100421
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit, in a Kanban view, the group representing
a new column did not contain a domain. Its domain should have combined
the view domain and the groupBy domain ([groupByField.name, "=", id]).
How to reproduce:
- Go to a grouped kanban view with a progress bar
- Create a new column
- Create a record in this new column
- Click on the progress bar to filter the records on a state
Before this commit:
All records corresponding to the selected state are displayed in the
column. (even the records that are not part of the column)
After this commit:
Only the new record is displayed in the column.
closesodoo/odoo#101096
X-original-commit: 1022262c6fcd51c8d4fc8024217542bb1f536d2c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When the kanban is grouped on a readonly fields,
it shouldn't be possible to drag and drop a record from
one column to another.
It was the case when the field was part of the view architecture,
but not when the fields wasn't part of the architecture,
despite we have the information as we have the field description
through the search view / the control panel.
This is a bug which has been introduced during the OWL conversion.
For instance, in 15.0, when grouping CRM leads by sanitized phone,
it wasn't possible to drag and drop records from one column
to another.
In master this is possible.
Besides, in the legacy code, the readonly information
is read from both the field in the architecture and the general
field descriptions:
- https://github.com/odoo/odoo/blob/67191359f2e71be85e6e72d64720bb2748008b3f/addons/web/static/src/legacy/js/views/kanban/kanban_renderer.js#L506-L515
In addition, compared to before,
this revision allows a new possibility compared to before:
Make draggable when grouped by a field which is by default
readonly in the model,
but which is set as `readonly="0"` in the view.
This is to be uniform with what is done in the list and form views.
closesodoo/odoo#101041
X-original-commit: 2a0f8d9ddba754cfc297b2a0de6e2c56990b1e61
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit properly removes the Many2ManyTagsField and
Many2ManyTagsAvatarField's placeholder when at least one tag has been
selected.
Steps to reproduce:
- In Contacts, open a partner's form view
- Edit and set at least one "tag"
- The placeholder is present next to the selected tags
Note: the placeholder was already present in previous versions.
Reported by FP.
closesodoo/odoo#101042
X-original-commit: 5976e19a31b9b0edaefc1079541514810d12b240
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this commit, when exiting a record in any way, the validity of
each of the fields was checked, even if not dirty. This means that the
user would be locked on a required field if that field got an invalid
value from the server, even with no given input.
In this commit, switching the mode on a record ("readonly" | "edit")
will not go through validation if the record was not dirty.
closesodoo/odoo#101000
X-original-commit: 8a8241503e41486e79ca19f9ca16f413cfabb08b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, in a list view, the context set on a m2o field
is not used when you edit the field to create a new record.
How:
- Go to a list view with a m2o field containing a context
<field name="m2o" context={"test":1}/>
- Edit the field the m2o field
- Click on "Create ..."
Before this commit:
The name_create method call does not contain the context defined
on the <field/>
After this commit:
The call to the name_create method contains the context defined
on the <field/>
closesodoo/odoo#100987
X-original-commit: dd1e7fab585ed5a691456632c20097ce443d9d69
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit moves the inline handlers of the `useSortable` hook
calls in the list and kanban renderers to proper class methods.
This allows said handlers to be overridden in child classes.
closesodoo/odoo#100986
X-original-commit: ec5ab1d389a0bdfb37c8b2c6766b6be1330085a7
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit implements the "name_get" method in the sample server.
This is required for m2o fields with the "always_reload" option.
How to reproduce?
go to an empty list view with sample="1" containing a m2o field with the
"always_reload" option
Before this commit
We have a crash because the "name_get" method does not exist.
After this commit
The view is rendered correctly with the sample data.
closesodoo/odoo#100985
X-original-commit: 4e53f92caf2527b15439eae041fcd238e2ed8145
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
- in Barcode > Inventory Adjustment
In the quantities add a decimal numpad
Issue:
Traceback
Cause:
The field is from type=number. This kind of field does not accept methods such `selectionStart()` or `selectionEnd` which causes an error: https://html.spec.whatwg.org/multipage/input.html#do-not-apply
Solution:
When of type=number, just return.
On Chrome, numpad won't be possible for regions such as Portugese - BR. They would have to use the keyboard key `period`, code '.' in order to be able to put a decimal via the keyboard.
In Firefox, HTML is parsing the input correctly if the browser settings are set to the right localization. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input#localization
opw-2956481
closesodoo/odoo#100953
X-original-commit: d95fbd80f63efbb47c9635e299f6ac417c5cb4c2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
In mass mailing, a button allows you to see selected records. In some case the
displayed view of selected records allows to alter records (ex.: cancel
attendee in event) which then affects the number of selected records. This fix
forces the recompute of the number of selected record when closing the view so
that it takes into account the potential modification done in the selected
record view.
In mass mailing, in the selected records view, the button is called "cancel"
but any action performed in the modal will still be applied. This fix renames
that button to "close".
Task-2921762
closesodoo/odoo#100933
X-original-commit: be4e409ec1c23f64e11796b05643e424a93aba9e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The useChildRef (used with the useForwardRefToParent hook) allows
to retrieve, from a parent component, a t-ref from a child.
Consider the following scenario:
- have a parent calling useChildRef
- have a conditional (with t-if) child calling useForwardRefToParent
- in the initial rendering, the child is displayed
-> ref.el points to the correct html element
- re-render s.t. the child is no longer displayed
-> ref.el is null, because the referenced element doesn't exist
- re-render s.t. the child is displayed again
Before this commit, at this point, ref.el will always be null,
even though the corresponding element comes back into the DOM. This
commit fixes the issue by correctly updating the ref, each time the
useForwardRefToParent hook is called.
closesodoo/odoo#100937
X-original-commit: 78d39c79993d1d63c189164f8104e5a3c90f2efd
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit transfers responsive related customizations for
ControlPanel, SearchView and SearchPanel to community which allows them
to render properly on smaller devices.
Note: a page reload (aka. F5) is required to properly adapt the UI after
a resize to a mobile-like size.
X-original-commit: 26a755610da36b01ba07ca224cc5937a672eb6a8
Part-of: odoo/odoo#100759
The `TagsList` component may be provided with a list of tags and a
number of tags that should be visible.
In the case where there are more tags then there are tags that should be
visible a ball with the number of remaining records is added with a
popover containing the names of the records.
However the popover contained plain text resulting in
`record1<br/>record2` instead of marked up html.
It will now use a tooltip template and more info.
X-original-commit: baf9711407a01ec196bf7de191372056aa4cab6e
Part-of: odoo/odoo#100764
There is a not that simple logic involving column widths in list
views, in order to optimize the space available for columns with
arbitrary long content (e.g. char or many2one fields). For that
reason, some columns have a fixed width. Before this commit, the
first column, containing record selectors, had no fixed width,
whereas it should be set to 40px.
This commit also renames o_list_controller.scss into
o_list_renderer.scss as this file only contains renderer rules.
closesodoo/odoo#100522
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Have a model with date(time) field with a group_operator (e.g.
"min"). Open a grouped list view of that model, containing that
field. Before this commit it crashed, because the aggregated
value of the date field, for each group, wasn't parsed (it was
still a string), whereas the code trying to display it expected
a luxon instance.
We could have easily fixed the issue by parsing the aggregated
values for date fields. However, it wasn't supported in legacy views,
and it would raise questions. For instance, views aren't designed
with this in mind (aggregated fields are often positioned to the
right, to leave enough space for the group's title). For that
reason, this commit simply restores the legacy behavior, that is,
we only consider aggregated values for "integer", "float" and
"monetary" fields.
The issue occurred in the Journal Items list view.
closesodoo/odoo#100595
Signed-off-by: Géry Debongnie <ged@odoo.com>
The goal of this commit is to get rid of the analytic tags as they were confusing, serving tag purposes as well as distribution on analytic accounts.
Everywhere analytic tags were used as a distribution have been replaced with a new widget that will dispatch distribution on analytic accounts. If there was an analytic account field next to the tags, it has been included in the distribution.
Analytic tags that were used simply as information tags have been removed.
To fill the new widget, there are now 2 kind of rules that will help fill and prefill it.
The first are applicability: previous groups have been removed, and have by replaced by plans. Each account is required to have a plan. These plans define when they are available in the widget: a default applicability per plan and applicability lines that can specify rules following the context of the widget.
The second one are distribution models, that will replace previous default rules but follow the same principles. The accounts (and so the plans) that will be given by the distribution model can override the applicability rules from before.
closesodoo/odoo#98914
Related: odoo/upgrade#3885
Related: odoo/enterprise#30743
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: Habib (ayh) <ayh@odoo.com>
Before this commit, some values entered in the percentage field could
be changed due to a rounding error.
For example, the value 28 was replaced by 28.000000000000004
How to reproduce it:
- Go to a form view with percentage fields
- Enter the value 28 in the percentage field
Before this commit:
The value in the input was replaced by 28.000000000000004
After this commit:
The value in the input remains 28
closesodoo/odoo#100559
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the data-hotkey attribute set on button nodes
in form views was ignored. This commit re-introduces the feature,
enabling the keynav on those buttons.
closesodoo/odoo#100563
Signed-off-by: Georis François (fge) <fge@odoo.com>
Since [1], a call to getView no longer returns the all models the
list of all their fields, because a lot of them aren't necessary.
However, it caused an issue in the following situation:
- have a form view with an x2many displayed as a list
- in the list, have a field or widget with fieldDependencies
(dependency on field A)
- in the arch, the x2many form view isn't inline
- in readonly mode, the user clicks on a row, which will open
the x2many form view
- since the form view isn't inline, a call to getView is done
- in the returned form view, field A isn't present.
Since [1], it crashed at this point because A wasn't part of the
known fields in the form view (but it was in the activeFields,
since they are shared between the x2many list and form).
This commit fixes the issue by adding fieldDependencies not only
in activeFields, but also in fields if not already there.
[1] 4636620004closesodoo/odoo#100495
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Scenario:
Open a record that is invalid in database (a required field is
empty), and click on the pager to go to another record.
Before this commit, we prevented the user from leaving the record,
marked the field as invalid and displayed a notification. This is
a weird UX experiment, since the user changed nothing (he did not
even enter edit mode). In this situation, since the record hasn't
been modified, the user should be allowed to leave. This is how
the legacy form view behaved.
closesodoo/odoo#100442
Signed-off-by: Géry Debongnie <ged@odoo.com>
Since [1], a call to getView no longer returns the all models the
list of all their fields, because a lot of them aren't necessary.
However, it caused an issue in the following situation:
- have a form view with an x2many displayed as a list
- in the list, have a field using the widget many2many_tags
along the color_field option
- in the arch, the x2many form view isn't inline
list must be present, without the color_field option,
and the color field must not be present,
- in readonly mode, the user clicks on a row, which will open
the x2many form view
- since the form view isn't inline, a call to getView is done
- in the returned form view, the color field isn't present,
the field using many2many_tags/color_field in the
list is present, and without the color_field option.
Since [1], it crashed at this point because A wasn't part of the
known fields in the form view (but it was in the fieldsInfo,
since they are shared between the x2many list and form).
This commit fixes the issue by adding the color field not only
in fieldsInfo, but also in fields.
[1] odoo/odoo@4636620004closesodoo/odoo#100479
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Before this commit, when a record from a relational model would start to
load, it would empty its `data` object. The issue is that a rendering
process can be initiated right after a record started loading. In kanban
views, this causes a crash since all records are always assumed to
contain values in their data objects.
This commit takes care to only clean strictly unwanted data when loading
a record instead of removing all the values, ensuring that records
always contain data.
closesodoo/odoo#100414
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, on compiling the field, a search is done to find the
label to link to the field. To do this search, the following field's
attributes were used: the `id`, which is encoded on the arch of the
view; if the `id` wasn't set, the `field_id`, which is an internal
technical attribute, is used, and if neither of these were set, the
'name', which is also encoded on the arch, attribute is used. These
attributes are compared with the content of the `for` attribute on the
label.
The issue with this, is that as the `field_id` is an internal technical
attribute and could never be found on the view arch, neither on the
content of the `for` attribute on the label. Leading to empty labels, or
labels linked to the wrong fields. This principally occurs when two
fields with the same name are found on the view.
Now, only the `id` attribute and the `name` attribute, which both can be
found on the view arch, are going to be used to search the correct label
to link to it's corresponding fields.
closesodoo/odoo#99399
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In a list view, group by a date or datetime field, then open a
group and select a record. Before this commit, it crashed, because
we didn't correctly consider the groupBy value, which is of the
form "fieldName:granularity" for a date(time) field.
closesodoo/odoo#100398
Signed-off-by: Géry Debongnie <ged@odoo.com>
"phone" isn't a valid input type, so it had no effect, except
breaking the tour system when a PhoneField input was the target
of a step, since the "consume event" was then "click" instead of
"input"..
closesodoo/odoo#100388
Related: odoo/enterprise#31437
Signed-off-by: Pierre Paridans (app) <app@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>
The HandleField widget should not be displayed in grouped list
view, probably because we do not support the resequence feature
in this situation. This is the legacy spec.
In the wowl ListView, we didn't implement this restriction. As
a consequence, some list views (e.g. DebugMenu > Open View) didn't
render correctly when grouped, because the presence of the handle
field (which is aggregatable) didn't leave any space to display
the group titles.
closesodoo/odoo#100356
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit, if a grouped list view contained an aggregatable
field (e.g. a float field) with a widget for which there's no
associated formatter (e.g. progressbar), the aggregate value was
left unformatted. It was for instance the case in the "My tasks"
list view, with the field "progress".
With this commit, the value is formatted according to the field
type, as expected.
Part-of: odoo/odoo#100356
A previous version tried to log qunit by module but it is still possible
to have multiple random errors in the same test occuring with different
combination. This will help to avoid duplicating automatically
parsed errors in this case.
Also skips the message if it is emppty/undefined.
Part-of: odoo/odoo#100238
Before: In a grouped kanban view, if all the groups are set to folded
by default, the view incorrectly thought it had no record. They were
simply not loaded and some method was not fetching the right data to
get the number of records.
It resulted in displaying the demo data and the no content helper,
making it impossible to see the actual data.
After: The number of records, despite no being fetch, is correctly used
in hasData and showNoContentHelper to fix the wrong behavior.
closesodoo/odoo#100234
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, we propagate all the slots to the SettingsPage. This
could raise an issue if the default slot (propagated) has a content, for
more information see: https://github.com/odoo/owl/issues/1256
Now, to avoid this, we only propagate the slots that are used on the
SettingsPage component, ie: NoContentHelper.
closesodoo/odoo#100362
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
The purpose of this commit is to improve the domain selector UX with
multiple little changes:
- The model field selector popover is now autofocused when opened
- Removal of a div that appeared during a hover on "add leaf" and
"ellipsis button"
- Caret icon next to the root node selector
- Minor CSS changes
task-2861497
closesodoo/odoo#99321
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before, the small "caret" to the right of the dropdown was only
displayed if the current Dropdown was a child of another Dropdown.
It is sometimes necessary to display this caret in a parent
`Dropdown` in order to make the user understand that there is a
dropdown if he clicks on the text.
Now, it is possible thanks to a props to display manually this carret
if desired.
Part-of: odoo/odoo#99321
[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>
In legacy, hide_model attribut on FieldReference was used to hide
the model input, but it was not implemented in ReferenceField
(new version).
closesodoo/odoo#99819
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Renaud Thiry