| Age | Commit message (Collapse) | Author |
|---|
|
This commit adapts the BasicModel to combine calls to `default_get` and
(first) `onchange`. When creating a new record, we now only call
`onchange`, which thus return default values and potential onchange
values.
Tests (and the MockServer) have been adapted accordingly.
NOTE 1. If the `default_get` within the `onchange` returns a value for
a field that is not in the view, we ignore it, and it won't be saved.
Before, that value was kept and sent upon save. This change in behavior
may prove problematic, although the overall risk is small. Decision has
been made to keep heavy comments and code snippets if we were to revert
back somehow to the previous situation.
NOTE 2. Putting a context on a many2one field may change the value
returned by `name_get` for that field. By default, the calls to
`name_get` are done by `onchange`. If the context on a field must be
used for `name_get`, one has to set the option `always_reload` to `True`
on the field. In that case, every `onchange` that changes the value
will trigger an extra `name_get`.
NOTE 3. Suppose that a one2many field has a list view with field A, and
a form view without field A. When adding a line, we now send all known
fields (main view and inline views) to the `onchange`, which may return
a default value for A. The value will appear on the list view, but not
in the form view. The former behavior was to call `default_get` with
the fields that occur in the form view only, and therefore field A would
be left to value `False`.
NOTE 4. A test surprisingly adds an extra call to `read`. The test was
actually wrong before. With the changes in MockServer, we now correctly
receive a command `[6, false, [1]]`, whereas before we received `[1]`,
which isn't a valid command, and which was ignored. As a consequence,
an extra `read` is done, whereas the test asserts it shouldn't. But it
already didn't work before (I checked by sending the correct command).
This needs to be bugfixed elsewhere (task-id-2323491): in a o2m with a
onchange and default order records on an other page than the first
should not trigger a `read`.
Task 2261084
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
With this commit, it is now possible to display sample (fake)
data in empty views, in the hope of easing user onboarding.
This can be enabled (in list and kanban views) with attribute
sample="1" on the arch root element. In this case, if there is
no data to display, sample data will be generated based on
heuristics (depending on field types and names). This can be
used in addition to the no content helper.
Task 2232801
X-original-commit: 7c8e627ff5029cb539d702705e5ce53d658c76ed
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Jérémy Hennecart <jeh@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
|
|
This commit refactors the way the decoration-xxx attributes are
applied to field widgets/components, in a way that it can be
overridden in a given field or component to generate the approriate
className. By default, 'decoration-x' applies className 'text-x'.
This will be necessary for the new 'FieldBadge' component, which
needs to apply 'bg-x' classNames instead of 'text-x'.
Part of task 2195254
|
|
There's a traceback when we edit an activity on a campaign
* Create a child activity
* Save the activity (not the campaign)
* Edit again the activity
* -> Traceback
Introduced in a9cebd5
Task ID 2220930
closes odoo/odoo#49698
X-original-commit: efa8952c39b0bcb0969013dc22e05b5d61ff1c66
Related: odoo/enterprise#9964
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
* account
This commit adds a new field registry for component fields.
This field registry is used to only register the new field components
and the other one should register the legacy fields.
Those two registries will be used together while all legacy fields are
not converted to owl component.
As the legacy registry now throws an error when adding a component
field the existing component fields (account.ShowGroupedList and
account.ShowResequenceRenderer) are moved into the new registry.
This commit also refactors some field managers (form renderer, list
editable renderer, calendar popover) to use the new registry and thus
support the component fields.
task id: 2193996
|
|
Let's assume a form view with an x2many list, containing itself
an x2many field (no widget, so simply displaying the number of
records). When a record of the list is clicked, a form view
opens and displays the same sub x2many field, with widget
many2many_tags. Both list and form views of the x2many aren't
inline (thus have to be fetched on demand).
Before this commit, it crashed when the user clicked on a row
of the x2many list.
The bug has been introduced by a9cebd5a, which wrongly removed the
code handling this specific situation. At least, now we have a
test attesting that this code isn't useless.
Note that the diff isn't as scary as it looks like (we just added
an if/else, and thus indented the former code inside the else
clause).
closes odoo/odoo#48116
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
|
|
Let's assume the following scenario in a form view:
- have a one2many field, say fieldA, displayed as a list,
containing another one2many, fieldB, (no widget, thus
displaying 'n record(s)')
- the one2many list is not editable, so there is a sub form view,
displaying fieldB as a list, and in this list some random field,
say fieldC, is displayed
- have a random field on the main form view, with an onchange to
populate the one2many
- set that random field s.t. the onchange returns something like
fieldA: [[5], [0, 0, {fieldB: [[0, 0, {fieldC: 'value'}]]}]]
- there is now a record in fieldA's list, displaying '1 record'
as value for fieldB
- click on that record to open it in a form view (dialog)
- in the dialog, in fieldB's list, we expect to have a single row
displaying 'value' as value for fieldC
Before this rev., it crashed when opening the record in the dialog,
whether the form view was inline or not.
The crash occured because fieldB was already in the list view, so
datapoints already existed for it (a list datapoint, and record
datapoints for records in the relation, in our example one record
datapoint). However, those datapoints didn't have the fieldsInfo of
the form view. When opening the form view, we added the fieldsInfo
of the form to the datapoint of the record we opened, but we didn't
recursively apply the fieldsInfo to its children. As a consequence,
when rendering the list view for fieldB in the dialog, we haven't
the information about fieldC, and it crashed.
Note that if fieldB wasn't present in fieldA's list view, it worked
fine because datapoints didn't exist before we opened the record in
the dialog.
Task 2120235
|
|
While x_name has long been automatically supported as an equivalent
of name, x_active was not.
This commit adds this behaviour OoB, both in the ORM and the web client.
On the ORM-side, a new `_active_name` attribute is supported on models.
This attribute specifies the field that should behave as an active marker
for records of the model. It is supported the same way `active` has been
until now (filtering by the `active_test` context key and toggled by the
`action_archive`, `action_unarchive` and `toggle_active` methods).
Although no check has been added on the field's type, it is assumed to
be a boolean field (the same way no check is present on the `(x_)name`
field).
On the client-side, the list view and form view now both support
detecting the presence of either `active` or `x_active` on records,
automatically adding an '(Un)Archive' button in the Action menu if such
a field is detected.
Note that the ORM implementation does actually need the field to be named
in any specific way, but since the web client has no mechanism to load
information regarding a model (the lifecycle of an action loading
includes loading the action, view and record(s) but no generic
information about the model itself besides what is included in the
views), we restrict the field's name to `(x_)active` to avoid confusion
as any other name would work at the ORM-level but not in the client.
In the future, the client might be able to more elegantly get
information about models, but this was not the scope of this change and
this solution should cover most cases.
Note that the `active` field will always takes precedence over the
`x_active` field to avoid confusing the polarity, even if both fields
are present on the model.
In the case of a custom field, it might be slightly annoying that the
default value of a Boolean field is `False`, which means that upon
adding the column, all existing records are automatically archived. This
can easily be worked around using an `ir.default` record for that
particular field and an update of existing records (e.g. through the
list view). The goal of this change was not to make it easy to add
support for custom active fields, but to make it possible - we have
therefore kept this implementation which introduces few changes while
adding enough flexibility for developers.
See https://twitter.com/zubair_shafiq/status/1202587553871880192?s=20
for more info regarding supporting any `_active_name` in the web client.
Co-authored-by: Raphael Collet <rco@odoo.com>
|
|
1/ Write a form view with a o2m field that has its own inline tree view
(no other view exist in db for the target model)
2/ Open that view in a mobile environment
3/ Instead of having a list view, you get a kanban view. No luck for
you, since the default kanban generated by `models.py` is an empty one,
your records are *invisible* \o/
From what I can tell, the previous condition made no sense:
```
if (there is a list view and a kanban view) <-- this seems absurd
then (use the list mode)
elif (there is no list view but a kanban view)
then (use the kanban mode)
else (use both modes)
```
The first condition seems absurd: it *actively* ignores a kanban view
if there is one. Even better, the list view whose existence it checks
is never there: it checks for a `tree` when it should be checking for a
`list`. In short, the first condition was *never* met, and you ended up
either with exclusive kanban mode or with both modes - even if you had
no existing kanban view for the target model...
This commit moves the normalization of `tree` into `list` before
attempting to process the x2many field's subviews. It clarify the usage
of `tree` vs `list` (cf. only use `list`) which prevents weird edge
cases like described above.
closes odoo/odoo#36237
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Co-authored-by: Adrien Dieudonné <adr@odoo.com>
Co-authored-by: Pierre Paridans <app@odoo.com>
|
|
|
|
Since the renderer does not know the view id, we moved the local
storage key computation up to the basic controller, which makes
more sense since the renderer is supposed to be inert.
The _processColumns function had to be moved in willStart however,
since it now needs the controller to respond to the trigger_up
and the controller is not present during the init of the renderer.
closes odoo/odoo#34051
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
|
|
closes odoo/odoo#35404
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
Before this rev. the searchpanel could only be activated in kanban
views (and it was specified in the kanban arch). From now on, the
searchpanel can be activated in any multi record view. It's arch
is moved to the search view arch (inside the <searchpanel> tag).
Task 1985921
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
Part of task 1896658
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
|
|
This rev. defines a searchPanel widget used in Kanban views to
refine search according to specific dimensions. This wigdet is
displayed as a sidebar to the left of the kanban view.
Part of task 1892462
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
|
|
closes odoo/odoo#30045
|
|
|
|
|
|
Use case: a x2m (ex: attribute values) displayed in a x2m (ex: attributes on
product) using different fields in different views (ex: tags in product form view
and list in product attribute form view). When opening the x2m record (in a
wizard) then going back on the form view, the tags are empty because the
`display_name` value has been lost when fetching x2m for the second time.
In this case, the list `fieldsInfo` needs to be updated with the existing
(default for tags) one so all the fields will be correctly loaded.
Task 1916891
closes odoo/odoo#29598
|
|
This branch introduces a large-scale reorganization of the
component tree generated by the web client. The short version is
that now, the control panel is a child of the view controller and
no longer a sibling. Graphically (and simplified), we go from
this:
webClient
/ | \
... ... actionManager
/ \
controlPanel viewController
/ \
to this:
webClient
/ | \
... ... actionManager
|
viewController
/ | \
ControlPanelController
/ \
CPRenderer CPModel
The motivation is that this work moves the code where it should be.
Before this commit, it was kind of weird to have code in the
controllers to render buttons outside of their root node (in
renderButtons). Also, the action manager had to take care of
coordinating search view states between view transitions.
So, this work simplifies the code. It also makes it easier to
extend. We see day after day that Odoo needs to take care of more
complex UI needs, and in many cases, these needs were quite
difficult to implement (we prefer spaghettis in our plates, not in
our code). The changes in this branch should open the way to
implement these features.
For example,
- it will now be easy to add the possibility of views (for example,
the search view or a new ControlPanel view) to add custom buttons
(of type action or object) in the control panel.
- Another need will be to serialize/ restore the state of the
search view across action boundaries (needed by the dashboard).
- Another example is the possibility for views to customize easily
the presence/absence of sub menus (filters/groupbys/favorites/
time range/...)
- Another need is an easier way for views/client action to customize
their control panel.
This commit also contains a large rewrite of the search view (so it
is more inline with our architecture and easier to maintain).
Part of task 1893568
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
|
|
|
|
When a view is loaded, it checks which fields it has to load.
In the case of a many2one, it could be the case that a context key is present in
one view and not in the other; if it happens, we should reload the data, as a
name_get result could vary.
opw 1891295
closes odoo/odoo#28298
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Image field widget need the __last_update field alongside them
for caching purposes, though that field should never be present explicitly
in the views
Before this commit, the dependencies of field widgets were not merged into
the model's fields definition, creating a traceback when adding an image field widget
into a x2many list
After this commit, there is no traceback and the image field works properly
closes #27545
|
|
In this commit, we implement a function which allow to combine
a list of domains into a single normalized using a 'OR' or an
'AND' operator.
We also refactor slightly py_utils.
|
|
The pyeval name is quite confusing, given that there is already an eval
and an evaluate function in py.js, and that the web.pyeval exports two
evaluate functions.
Since this file is more about odoo specific customization to py.js, it
is renamed in py_utils to better express its intended use.
|
|
It is sometimes useful to be able to customize slightly the color of a
field depending on some conditions on the current record.
For example, imagine that we want to show a VAT number field in green/red, if
it was validated or not. To do that, we can add a field with an
onchange, and simply add decoration-danger and decoration-success
attributes to the field.
|
|
Before this rev. the `column_invisible` and `default_order` attribute, set in a
x2m list view were only taken into account for inline views.
The technical reason behind is because non inline views are fetched after the
main view processing.
Non inline x2m list views now correctly handle these two attributes.
|
|
This rev. refactors the way the view's arch is parsed in BasicView,
so that it can be extended specifications of the BasicView to
handle other tagnames that 'field' (which is basically the only
one handled in BasicView).
|
|
A crash occured in several Studio tests that have just been
forwardported to saas-11.2, because of a line that hadn't been
adapted in rev. cb339842 (technically, the previous code was
correct, but it crashed when viewInfo.fields was undefined, which
doesn't happen outside the tests environment).
|
|
|
|
Let's assume a one2many list view inside a form view, displaying
a single char field A. There is an onchange on the form view
returning a command 0 (CREATE) for the one2many. The command 0 only
specifies a value for field A. The one2many list isn't editable, so
when a sub-record is clicked, it is open in a form view (in a
dialog). In this form view, an x2many field B is displayed in a sub
list or kanban view.
Before this rev., it crashed when the user tried to open the
created one2many sub-record (returned by the onchange) in the form
view, because of the presence of the x2many field B, which wasn't
correctly processed by the BasicModel (its value was undefined,
whereas it must be a valid, empty, dataPoint).
Moreover, the limit of the x2many field B wasn't set, so a pager
was displayed as soon as it contained at least one record.
Fixes #22050
|
|
In Less, the size_class XXS is defined and used in media queries.
This rev. adds it in JS for sake of consistency.
Code in addons comparing the size_class needed to be adapted due
to the new XXS size_class.
Moreover, we now use the helper 'config.device.isMobile' everywhere
we should, instead of manually comparing the size_class.
Finally, we changed the way the config.device has to be specified
in the test environment. From now on, only the size_class should be
set, and the isMobile flag is computed automatically.
|
|
*: mail, web_diagram
|
|
Before this revision, only the FormView allowed to reuse the same datapoint.
This was only used when opening a FormViewDialog when opening the form view
of record in a one2many field.
However, this could be useful in other places for other views. In Studio for
example, we need to instantiate a x2m view without the parent view ; we thus
need to be able to reuse the same model for all basic views.
|
|
Let's assume the following situation: we have a one2many field
displayed as a list in a form view. The list isn't editable, so
when a subrecord is clicked, it is opened in a form view in a
dialog. In this form view, there is a relational field X that is
not in the list. In the main form view, there is a field with an
onchange. When its value changes, the onchange returns a new
value for the one2many: a command 5 (delete all), and a command 0
(create) with a dict of values containing a value for X. However,
as X is unknown as long as no subrecord has been open in the dialog,
the value for X can't be processed (we don't know the type of X,
so we don't know how to process the value).
Before this rev., when this happened, we discarded the value of X.
This caused an issue for example in the Quotation form view (with
website_quote installed):
- create a new Quotation
- set PartnerShip Contract as quotation template -> the onchange
returns two 'create' commands for the order_line one2many
- click on one of the two subrecords in the one2many -> error.
This rev. ensures to keep changes on unknown fields. We keep them
unprocessed, and once the form view is opened, we process and
apply them.
|
|
Suppose that there is a one2many list in a form view containing
a field F, displayed with no widget, and that F is also displayed
in the one2many form view (opened when clicking on a record of the
list), but that in this form view, F is displayed with a widget
requiring specialData (additional data to fetch alongside the
record), e.g. widget="domain".
Before this rev., it crashed when this happened because those
specialData weren't loaded when opening the related record.
Credit goes to @pga-odoo for reporting the bug and reproducing it
in a test.
|
|
When we load a field data with many2many_tags widget, there is no views in the
field info but instead we need to fetch the default fields,
e.g. color, display name and id.
|
|
* should use the optional context when opening a formViewDialog
* calendar must send the context for writing or creating records
|
|
- When an one2many is displayed in a list view, the field data are not fully loaded
since only the number of record is displayed. Then when the related form view
is opened the one2many fields displayed need to be loaded.
- Optimized the fetch of x2manys without doing an useless rpc
if we don't need all the fields but only the relation records ids and adapt
the tests for this optimisation.
- Fix wrong inheritance for kanbanmany2many_tags
|
|
* account, mail, sale
Since the views refactoring, modifiers were not properly handled
anymore (readonly/required not recomputed, use of readonly/required
of "python field" instead of "view field", ...). This commit tries to
implement a system which allows to handle the modifiers (re)computation
the same way for all the basic views.
For this to work, many specialized renderers behaviors have been moved
to the basic renderer so that more mechanisms are shared (especially by
the form renderer and the list editable renderer). The list editable
renderer is hugely impacted by this commit.
Here is a list of key changes:
- The basic renderer now has a `_renderFieldWidget` function which is
used without modification by the form and the list renderers.
- Modifiers have to be registered thanks to the basic renderer
`_registerModifiersData` function (this is done automatically for
fields by the `_renderFieldWidget` function for example).
- All instantiated widgets are accessible, organized by record, and
ordered in a special basic renderer variable.
- The code which resets the widgets of the form view and the code
which updates the row of a list editable view is now shared in the
basic renderer and now also automatically updates the DOM according
to the reevaluated modifiers.
- The last point has an huge impact on list editable renderer: all the
widgets have to be instantiated when editing a row (even readonly and
invisible ones) as they can be switched to editable/visible during
edition (after a modifiers update).
- `replace_element` and `readonly` options of `AbstractField` are
useless: widgets are now always replacing the list editable cells
in edition and the `readonly` widget mechanism is replaced by the
notion of 'focusable' widgets.
(see `AbstractField.getFocusableElement`)
- The 'tab' navigation mechanism is impacted by the previous point,
some code sharing have been done in basic renderer for this too.
- `AbstractField` does not care anymore of the 'required' status, this
is the view responsability to check that a required field has a set
value on save.
- Some list editable bug fixing (e.g. it was possible to edit multiple
rows at the same time, it was not possible to navigate towards the
previous field, crash on o2m add an item click, ...)
- The mockserver now properly simulates server modifiers computation.
- ...
Note: list editable style may be worse than before this commit but a
CSS update is coming in a few days.
|
|
Assume that there is an onchange on a form view that upates the
records of a one2many field. Before this rev., if the user edited
one of those one2many records (in a dialog) after the onchange,
the onchange values were lost.
|
|
A record of the basic model may need to be displayed in different
views (e.g. a o2m record is displayed in the, e.g., Kanban view
inside the main form view, and if clicked, it is also displayed
in the form view opened in a dialog). However, the fields present
in those views may differ.
The previous implementation of fieldsInfo in the record didn't
handle that, as it was a dict whose keys were field names. With
this commit, the fieldsInfo is dict whose keys are view types, and
the values are dicts whose keys are field names (the fields of
the corresponding views, with they attrs in the view).
This allows to create multiple o2m records in a row in a form view.
|
|
* Data manager load_view returns a viewInfo object
* ViewInfo contains: the arch, fields and fieldsInfo objects, and some extra informations
* The fields come from the server and are frozen, without any view attributes (depend of the model).
* The fieldsInfo contains every view attributes and informations.
|
|
* Load views before loading data.
* Load the view used by the mode (by default use kanban for mobile)
* Add attribute useSubview on the widget to load view of the related model
|
