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
This commit fixes a race condition in the RelationalModel, which
can be identified by a ListView test [1], with a subset of addons
installed. Before the fix, we didn't wait for the record to be
reloaded before re-rendering the list. It could then crash because
the data object was empty (not yet filled with values).
This commit also prevent unnecessary reload/rerendering after an
urgent save, i.e. when the user is closing the tab.
[1] editing a record should change same record in other groups when
grouped by m2m field
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>
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>
For now, the graph view completely ignores the order attribute set on
its arch root node if written in the correct way, i.e. with "asc" or
"desc" (lower case). We fix that.
closesodoo/odoo#100302
X-original-commit: 0fb64bef16914937cf4a1d1618fb58ade6d16f14
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Before this commit, a record quick created in kanban would have values
left from the quick create form view in its `data` object, that would
then be used by the model of the parent view to perform onchange
actions.
This would cause a crash if said values were set on a field not included
in the parent view's active fields.
In this commit, records data are cleared at each load, ensuring that
they only contain values for their current active fields.
closesodoo/odoo#100182
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the groups returned by `web_read_group` were
unpacked using the current 'group by' field name, and not the entire
'group by' value (potentially including a granularity for date/datetime
fields). This caused mismatches in some cases and the value couldn't be
retrieved.
Also, a needless 'sum_field' parameter was passed to the
'read_progres_bar' calls, which does not exist in the request API.
This commit fixes the first issue and removed the excess parameter.
closesodoo/odoo#100149
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit aims to make the behavior of the mocked 'read_progress_bar'
requests closer to their server implementation.
Namely, the returned dictionnary is supposed to contains the display
names of the current groups in its keys. This was not the case and has
been fixed.
Part-of: odoo/odoo#100149
Now that web_studio no longer uses the legacy graph and pivot views and
that all their extensions have been converted, we can finally remove
them from the code base.
closesodoo/odoo#99734
Related: odoo/enterprise#31112
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, an empty many2one field in readonly rendered
an empty `<a href"...">` node. Even though that link was no visible,
it had a non null width, and was thus clickable (the cursor changed
when hovering it). When clicked, it opened the form view of the
comodel, in create mode.
This commit fixes the issue by not rendering anything if the value
is false.
closesodoo/odoo#100158
Signed-off-by: Géry Debongnie <ged@odoo.com>
"Notebook" component had to be adapted to make the use of tabs
more consistent trough the app. The component now allows a use of
default tabs style in a vertical display
task-2950591
Part-of: odoo/odoo#98706
Before this commit there is a widget `many2one_barcode` that allows
to scan a barcode.
After this commit, we have converted it to OWL, but it's more than a new
component. From now, the logic is in the basic Many2One as a
property/option (`canScanBarcode`) and we also have the equivalent
Component (`widget="many2one_barcode"`). This choice has been made to
support multiple use cases (e.g. having the product_configurator and the
barcode on the same product field).
Note:
now we use the `browser` class to allow to patch the browser feature
during testing.
Part-of: odoo/odoo#100082
Move all file related to Barcode scanner (JS/XML/CSS)
Note: also the CSS class is renamed as it's not related to mobile
exclusively
Part-of: odoo/odoo#100082
Before: the command service was used inside components instead of the
hook. It introduced problems as the commands were not unregistered.
The commands were added multiple time to the registry.
closesodoo/odoo#100135
After: It uses the hook, "it just works".
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
We don't want any padding in those dialogs. The presence of the
padding was a consequence of the rewritte of that dialog in owl.
It is a frequent usecase to remove the padding from the body of
dialogs. We thus introduce a new props on Dialog and when this
props is set to `true`, we do not set any padding on the body.
This commit refactors other usecases to make them use the added
props.
closesodoo/odoo#100045
Signed-off-by: Géry Debongnie <ged@odoo.com>
In the PDF reports, the general spacing is too narrow, for
example in tables, in the address lines etc. This commit
upsizes a bit the line-height for the majority of text/digits-based
content.
taskID 2977261
closesodoo/odoo#99837
Signed-off-by: Kevin Baptiste <kba@odoo.com>
In this commit, we simply set 'position' to 'sticky' on 'o_header_affixed'
to avoid to manage it's position with 'padding-top' and 'right'.
- 'padding-top' css property was used to compensate the navbar height
at the moment where the stacking context change because of the
fixed position.
- 'right' css property was used to prevent the menu to overlapp
the scroll bar.
Part-of: odoo/odoo#99338
XML files are now declared in python module manifests. During the qweb
't-call-asset' directive, assetbundle will fetch the declared xml files,
apply the inheritance (t-inherit) and create a javascript service (for
eg: 'web.assets_backend.bundle.xml') which is added at the end of the
*.js mimifier file.
When the debug mode is activated, comments are added in the template
indicating which file the template comes from as well as the
inheritances applied to it.
****
JavaScript:
assets.js (module @web/core/assets) takes care of loading libraries,
javascripts and styles.
`loadJS(url)` (loads the javascript and returns a resolved promise when
the templates are also loaded via the '*.bundle.xml' service)
`loadCSS(url)` (loads the style a resolved promise when the file is
loaded)
`loadXML(xml, app=assets.defaultApp)` (load template into
application/owl, used by the `*.bundle.xml` services)
`getBundle(bundleName)` (get the bundle descriptor)
`loadBundle(desc)` (load the files and bundle from a descriptor)
templates (XML element content all owl templates)
A new `ready(serviceName)` method on boot.js lets you know when a
service is loaded are the require.
The xmlDependencies attribute no longer exists.
Python:
The xmls taken into account by assetbundle.py, applying `t-inherit`
inheritances and adding an `name_of_the_bundle.bundle.xml` service in
the generated JavaScript file.
****
Every manifest changes is into the next commit, except 'web_tour' in
this current commit as example.
Part-of: odoo/odoo#95500
A typo fix is added.
Fix error from loading xml while widget is destroyed. Now that the xml
templates are loaded in the bundle, the error appears more frequently.
Part-of: odoo/odoo#95500
This commit addresses 2 issues in kanban views with progress bars:
1) When updating the field on which the progress bars are computed in a
record, an inert "Load more" button would appear
2) After updating said value, the progress bars would not be recomputed
Both of these problems have been fixed.
Part-of: odoo/odoo#99748
This commit is three-fold:
1) we now honnor attributes `create` and `import` which can be
set to a falsy value in archs (and in these cases, we disable
the import feature)
2) we converted the base_import test suite to use the owl views
3) we whitelisted the base_import addon for the lint/prettier
script
closesodoo/odoo#100026
Signed-off-by: Géry Debongnie <ged@odoo.com>
Tooltips (and aria-label) should be used when the content of the element
is not self explanatory; but in the case of the create/save/edit buttons
available in several view control panels (kanban,list,form), tooltips
with dubious usefulness were added (e.g. "Create record" when you hover
on a button labeled "CREATE" is not really an information bomb).
Since these buttons tend to be used in tours, and the "coucouilles"
of the tours will also be some sort of tooltips, it means that you
can have frequent weird visual interactions between nunuts and stupid
tooltips.
This commit removes these stupid tooltips.
Feedback-2973374
closesodoo/odoo#100078
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Imagine a form view with a one2many editable list, containing a
required field. Open an existing record, s.t. in the one2many
there's already a sub record. Modify that subrecord, s.t. the
required field is unset (e.g. empty it, or it can be unset from
the beginning, but then modify another field). Then save the main
record. Before this commit, the record could be saved.
In this situation, the modified one2many record isn't valid, so
we shouldn't be allowed to save. The view should remain in edition
and the invalid field should be indicated.
This commit fixes this issue.
closesodoo/odoo#100059
Signed-off-by: Géry Debongnie <ged@odoo.com>
On mobile, in list view's selection mode, both the left & right bottom
parts of the ControlPanel are displayed but only the left one
(containing the selection banner and actions menu) should be displayed
(and take the full width).
Also, small alignment adjustments.
closesodoo/odoo#99483
Related: odoo/enterprise#31269
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this commit, if the Layout's `display` props is a dynamic value
coming from the parent Component (ie. a getter on the component that
controls which parts of the ControlPanel should be displayed), this
value isn't applied after the first initialization.
This commit fixes it by extracting the `display` logic applied in the
constructor to a getter (moving from initialization only to once
called).
Part-of: odoo/odoo#99483
The purpose of this commit is to add a quick create button at the bottom
of each column in order to facilitate the user when he wants to quickly
create a record.
It was already possible to quick create a record in the kanban view.
To do so, the user needed to click on the quick create button placed
on top of the kanban view, forcing the user to scroll to the top of
the view if he consults records at the bottom.
task-2823605
closesodoo/odoo#98703
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
In a form view, modify a record s.t. a required field is unset,
and then click on the pager to navigate to the next or previous
record. Before this commit, a notification was displayed (because
a required field is unset), but we switched to the other record
anyway.
This commit restores the desired behavior, which is to stay on the
current record to let the user fix it or discard it.
closesodoo/odoo#100050
Signed-off-by: Géry Debongnie <ged@odoo.com>
From a (e.g.) list view, click on "Create". In the form view, fill
in some fields, but leave a required field empty. Click on the
breadcrumbs to come back to the list. Before this commit, a
notification was displayed (because some required fields are
unset), but we left the form to come back to the list anyway.
The desired behavior is to stay on the form view, and display a
notification indicating that some fields are invalid.
In legacy views, we rejected promises to indicate that we couldn't
leave. This is a pattern we tried not to use anymore in new code.
Instead, we return a promise (if the method is async obviously)
which resolves to a boolean value, indicating if it works or not.
As a consequence, the action service wasn't properly dealing with
new views, as the promises they return always resolve.
This commit fixes the issue by adapting the code in the action
service.
Part-of: odoo/odoo#100050
Before this commit, the title of the SelectCreateDialog opened
when clicking on "Add a line" in a Many2ManyField was always
"Select Records" (the default value), whereas in this case, we
want to see "Add: something", where `something` is the `string`
attribute of the field (which can be overriden by an attrs on the
field node in the arch). This commit restores the desired behavior.
closesodoo/odoo#100046
Signed-off-by: Géry Debongnie <ged@odoo.com>
Have a x2ManyField displayed as a (non-editable) list view, and
with a context defined on the x2m field node in the arch. Before
this commit, this context wasn't propagated to the dialog opened,
for instance, when adding a new record. It is now the case.
To make the tests pass, we also needed to make a slight change in
the BasicModel, as it didn't correctly process the context when
adding a new record with additional contexts (e.g. in x2many list
views with custom `<creates>`.
closesodoo/odoo#100000
Signed-off-by: Géry Debongnie <ged@odoo.com>
Denis Ledoux