| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
Issue: wysiwyg asset slow down the loading of the website, error
inadvertently introduced: https://github.com/odoo/odoo/pull/29775
The assets are now loaded assynchroneously, when the editor is needed,
its assets will be loaded.
closes odoo/odoo#30700
|
|
Task #1871557
Purpose
=======
- Configure a product from a sales order as easily as in the ecommerce
The backend uses the same template as the frontend to configure a products and its options
- Display optionnal products of optionnal products in the "sale options" section
- Allow adding exlusions to some combinations of the product and/or
to some combinations of the optionnal and accessory products
Specification
=============
PHASE I
1. Improve the "Add to cart" with optional products
- When you add an option to cart, move the product to the cart & show the options of this option
- Don't open the option wizard if no option available (in case this module becomes generic,
it's better to skip this step when it's not needed)
- Display the options right under their related product in the cart
2. Do not allow to add the product as an optional product for itself
Why ?
- No functional sense
- Creates issues in the add to cart wizard
3. Exclude some attribute combinations within the product or with related options and accessory products
- Rename VARIANT PRICES button -> CONFIGURE VARIANTS
- When you click this button and select a value, open form view rather than inline edition
- Form view of variant values:
- Attribute
- Value
- HTML Color Index
- Attribute Price Extra
- Not Compatible with: o2m tab with 2 fields: Product AND Attribute Value (of this product)
[m2m tag selection]
- in any new line, autocomplete the current product by default
- Tooltip: A list of product and attribute values that you want to exclude for
this product's attribue value. Also applies on optionnal and accessory products.
4. New option to configure a product in a sales order line
- This option is only visible if the corresponding option is activated in the sales settings
- It opens a wizard to select a product template, configure related attribute values
and select optional products (based on frontend view)
- Attributes not compatible with other selected attributes should not be selectable
- Must work like in the frontend
|
|
Before this commit, the only way to deal with the same tax either with price included or not was to duplicate it, one with the price included checked.
This commit add a new boolean on the reconciliation widget propositions to decide if the tax must be used like a price included tax or not.
PR: 17040
task: 32717
|
|
Before this commit, Odoo used checkboxes in three different ways:
- A simple <input type="checkbox"/>, mainly in the frontend. The style
is browser dependant.
- Same as above but with the BS3, checkbox structure. The style is still
the same, but the alignement is supposed to be better (which is not
always the case).
- The Odoo official structure:
```
<div class="o_checkbox">
<input type="checkbox"/>
<span/>
</div>
```
which allows to have a cross-browser checkbox style and correct
alignements.
The goal after this commit is to only use the BS4 *custom* checkbox
structure to achieve the same goal as our official structure (and
remove that one):
```
<div class="custom-control custom-checkbox">
<input type="checkbox" class="custom-control-input" id="customCheck1">
<label class="custom-control-label" for="customCheck1">...</label>
</div>
```
/!\ Labels are now required (use a zero-width space if necessary)
|
|
Today, Odoo is really tricky to use without seeing the screen, it must be improved to be usable.
This PR forbid to use labels without a "for" attribute, add some title, rule and aria attributes in HTML. With that, Odoo will be fully usable with a screen reader.
* [IMP] Labels must have a for attribute. Improve accessibility.
* [IMP] Better error message when trying to read a missing cached value
* [FIX] Add some aria-label and title attributes for screen readers.
* [FIX] Template name is not included in the error message in case of SyntaxError in QWeb
* [FIX] Improve the Tour failed at step error message to be more explicit.
* [IMP] Add aria-labels
* [FIX] Add missing aria-label on failing test
* [IMP] aria-hidden means hidden. Fix all bad aria-hidden and hide aria-hidden for all.
* [IMP] Color names on kanban views and many2many tags
* [IMP] Add some checks on views for accessibility.
* [IMP] Add `alt` attribute on `img` tags.
* [IMP] Add aria-label and title on non-described icons
* [IMP] Add button role to widgets with btn class
* [IMP] Translate aria and formatted attributes.
* [IMP] Remove wrong aria-labelledby
* [IMP] Add menu role on dropdowns
* [IMP] Buttons must be focusable
* [IMP] Add aria attributes on progress bars
* [IMP] Improve accessibility of basic widgets
* [IMP] Change main layout to more semantic tags
* [IMP] Add menuitem role when missing
* [IMP] Remove wrong role='presentation'
* [IMP] Improve accessibility of tab panels
* [IMP] Add aria-invalid on invalid fields
* [IMP] Add aria-sort on ordered columns
* [IMP] Add role on alerts
* [IMP] Use dialog role, header, main and footer tags for modals
* [IMP] Add labels on o_status
* [IMP] Improve accessibility of kanban view with feeds and articles
* [IMP] Add alerts in case of new messages
* [IMP] Add widget, navigation or img role to aria-labelled items
|
|
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.
|
|
Reproduce the issue:
- open the manual reconciliation (it is a client action)
- add a reconciliation (using the + sign)
- expand it (using the > sign)
- put the focus on the first field and hit TAB
--> you would expect that the focus moves to the second field
--> what happens is: the focus stays on the first field
Before this fix, when in a client action (or any place that contains
fields) that contains fields, the keyboard navigation did not occur
correctly because the default behavior of the TAB key was prevented.
After this fix, if the navigation_move event was not stopped, we allow
the default behavior of the TAB key.
|
|
This fix allows the documentation to be built again.
|
|
The goal of this commit is to allow fast entry of the same model using
the keyboard for navigating through the form once, by blocking the user
from advancing in the form if there is a required field or once they
went through the form once to get them to a primary action (button)
This commit includes the following changes
1) Enable moving forward from field to field using the TAB key
2) Entering the one to many and many to many using the TAB key
a. When entering it, set the focus on the "add new line" link or
button
b. When adding a new line, set the focus on the field visible
editable field of the new line
c. Discard adding a new line with ESC key
d. If the user leaves the first field empty and uses TAB, we
will cancel the adding of a new line and move to the next
field of the form
3) When a field is required and not filled in, do not allow the user
to move out of the field using the TAB key (the user is still
allowed to use the mouse though), mark the field as invalid
instead
4) After going though the form once, using the TAB key on the last
field will move the focus to the first primary button of the page
5) When the focus is on a primary button (EDIT/SAVE), the user cannot
move the focus forward using the TAB key. Hitting TAB again will
display a tooltip telling to hit ENTER to activate the button.
The mouse is still available to move the focus.
6) When the user saves, the focus is placed on the first primary
button of the form renderer (like VALIDATE for a new invoice)
7) On dialogs, primary buttons should stop the users from moving out
of them, and showing a popup if the user tries
8) When closing a dialog, the focus will be moved back to the widget
that opened it.
This commit does not include the following features
1) Navigation with the keyboard on a selection one to man
2) Navigate between tabs in a form using the keyboard
3) Cancelling the adding of a new line in a many to many using the
ESC key do not set the focus correctly
4) Enhancing the focusses fields (like blue underline)
|
|
|
|
Cleaning dead code from these commits that have been reverted:
41fe7f9d1113d026b226b136b4477aaaf9f1f638#diff-54fd886cc58f994ad518ee72df4d3edeR50
2a5488619da22cfd901963dd141e722b195e82ab#diff-f96b339a9374f74489f1f98755e9787bL9253
41fe7f9d1113d026b226b136b4477aaaf9f1f638#diff-86d6d41b5bb7499bf055258d05549d59R3111
With these final changes, we hope to stop the many issues that have occured with
binary fields, from these commits:
255e8ca3d92e3a77d7c2a145677623518bc2f978
7813a8e714f268983b0be88827ae1c8ad887e6c7
41fe7f9d1113d026b226b136b4477aaaf9f1f638
2a5488619da22cfd901963dd141e722b195e82ab
What remains is the format of binary fields in list views without widgets,
which shows the bin_size instead of the base64 string representation...
... Rest assured, the computation is in JS, so there are no 'bin_size'
shenaningans!
|
|
Field widgets now have a key 'context' that let them
extend the context of the dataPoint (e.g. list).
In particular, widgets on binary fields enforce the contextual
item {bin_size: True}, so that the server gives the size of the
binary field as its value, instead of its content.
This change on binary fields reduces network load when accessing
a view with binary fields.
|
|
|
|
As a way to optimize loading, images are not necessarily fetched in db.
They have, in their url a "unique" parameter, which is the last_update date on **the record** and controls on the python-side whether it should get the image from a cache or from the db.
Before this commit, this __last_update field wasn't present in the view, so it wasn't fetched, and writes on a model's image worked but did not refresh.
The image displayed was the old one.
After this commit, when the image field widget is present, we force the loading of the __last_update field of the record.
Upon update, the image displayed is the new one.
OPW 777552
closes #20457
|
|
|
|
issue: When reorder each line trigger an onchange on the line (if they are an
onchange linked to the field) and one onchange per line on the parent.
Adding an option doNotNotifyChange to avoid the trigger on the parent.
|
|
Problem occured in the MRP Production wizard (with a consumed
product tracked by serial number). The opened record is a new
record, and its one2many has 2 default rows that are prefilled.
If the user edited one of the quantities in those rows, and set
an invalid value instead (e.g. a letter), the row was removed
without notice when it was focused out. This was because the
model wasn't aware that a change has been done on the record,
and as the record was flagged as new, it was simply abandonned.
|
|
Problem occured in the MRP Production wizard (with a consumed
product tracked by serial number). The opened record is a new
record, and its one2many has 2 default rows that are prefilled.
If the user edited one of the quantities in those rows, and set
an invalid value instead (e.g. a letter), the row was removed
without notice when it was focused out. This was because the
model wasn't aware that a change has been done on the record,
and as the record was flagged as new, it was simply abandonned.
|
|
|
|
should discard the edited row, but not close the dialog. Before
this rev., it was closing the dialog.
|
|
Fix a bunch of ill-documented/incomplete/incorrect method docs
Without this, the automatic doc generation does not work.
|
|
|
|
The rev. https://github.com/odoo/odoo/commit/99ae418bf24171fbc6bb27584059c27efb857e77
introduced a trigger_up `mutexify` when quick creating a record in a many2one ;
this broke the behaviour when the many2one was standalone (because it has no
BasicController and mutexify is handled in the latter).
An attempt to fix this issue has been made in the rev. https://github.com/odoo/odoo/commit/e83c3e2678500c9bf2c17b4d23ae9a294ebafaa7
by adding an option `standalone` in the field widget options. In this case,
the action was directly executed instead of the trigger_up. While this correctly
works, this implies that the option needs to be added in every standalone
many2one (and only many2one as the others won't use the option), which is not
very convenient.
An other attempt is made in this rev. by moving the mutexify handler from the
BasicController to the FieldManagerMixin ; as a widget that instantiates a field
widget needs to extend this mixin, both cases will work and we won't need to
specify the option anymore.
This commit thus partially reverts the rev. https://github.com/odoo/odoo/commit/e83c3e2678500c9bf2c17b4d23ae9a294ebafaa7
|
|
The pad widget does something unconventional: it creates the pad url
only when rendering in edit mode. This was done to prevent creating pad
by default for record in readonly mode.
Because of that, if the user clicks on create, then discard, the record was
considered dirty, so a confirmation modal popped up. In this commit, we
just make sure that the initial setValue from the rendering does not
'dirty' the record.
|
|
Execution of actions is usually done with trigger_up, which delegates
the action execution to the widget's controller.
This is troublesome for actions done on widgets that have no
controllers, like widgets in Studio for example.
The commit fixes this by adding a standalone option for AbstractFields,
if the flag is true when instantiating a widget, the action will be
called directly from within the widget object and will not be propagated
upwards.
A test to verify that this works properly has been added as well
|
|
When an invisible x2many field is modified by an onchange, we had a
crash because the reset function did not return a deferred in that case.
This happens because the signature of _render in AbstractField allow for
an undefined return value, but the reset method should return a
deferred.
This was an issue for example in stock: editing the
pack_operation_product_ids one2many field in a stock.picking could
trigger an onchange on another invisible one2many (with no inline views).
|
|
Field widgets must format and parse values according to the widget
type, not to the field type. For example, if a monetary field is
inserted in a form view with widget="float", the field's value must
be formatted with the float formatter, not the montetary one. This
wasn't the case before this rev.
|
|
Commit 9966e4b added calls to preventDefault() on the keydown event
for left, right, up and down arrows, to prevent the page from
scrolling. However, it also prevents the cursor from moving inside
the inputs. Since the initial issue only concerned checkboxes, this
rev. moves the preventDefault() calls from AbstractField to
FieldBoolean.
|
|
The autofocus worked fine when switching from 'readonly' to 'edit',
but not when clicking on 'Create' from the multi-record view. This
was because in this case, we were trying to focus the field while
the view wasn't in the DOM yet. This rev. ensures that we wait for
the view to be appended to the DOM before trying to set the focus
on the default field.
Also ensures that the first visible field is correctly focused.
Before this rev., if the first field was invisible (or simply
not focusable), no field was focused.
Credit goes to @msh-odoo for the preliminary work.
|
|
The 'Add an item' button of one2many editable lists is deactivated
once clicked (since rev. f9a1241) to prevent concurrent record
creation. It is re-activated when the record has been created.
Unfortunately, it might happen that the record is actually not
created, so in this case the button is never re-activated.
This happens for example on the customer invoice form view, if
the user tries to add a line before selecting a partner.
|
|
Problem occured with checkboxes in editable lists: when pressing
up, down, right or left with the focus on a checkbox, in addition
to navigating in the requested direction in the list, the page
scrolled (if there was a scrollbar of course). This was because the
event wasn't 'preventDefaulted'.
|
|
Suppose that there is a many2many list (non editable) in a form
view. When one of the many2many subrecords is edited (from the
form view in a dialog), it is saved directly when the user clicks
on 'Save' in the dialog.
Before this rev., if the user clicked on 'Save' in the main form
view after editing a m2m subrecord, a 'write' RPC was done, whereas
there were nothing left to save (as the subrecord had already been
saved).
|
|
It is not really easy to handle discard operations. We need to handle
the discard in editable lists, and in x2manys. This is not exactly the
same code, but most of this was done by moving the discard method from
the formcontroller to the basic controller.
With this commit, the user can now discard the changes for the current
record by pressing ESC. If the record is new, it will remove it, if
not, it will ask for confirmation before.
|
|
Before this commit, when editing a many2one (with an onchange) by
clicking on the small form button on the right, then changing something,
then saving the modal dialog, no onchange was triggered, because,
technically, the value of the many2one was not changed, only the values
from the record pointed by the many2one were.
The same remarks applies to many2manys.
To see this issue in odoo, you can open a product (technically, a
product.template) from the 'Catalog' menu in sales, then edit it, then
click on the small form view icon next to Internal Category. This is a
many2one (categ_id) with an onchange. In the form view dialog, change
something, for example costing method, then save. The res_id of the
internal category was not changed, but an onchange should still be
triggered.
|
|
Before this commit, when creating a new record, we only looked at the
main fields to determine if a call to onchange was needed. This was not
enough, since sub fields (fields in a one2many for example) can have an
onchange.
This was an issue only for new records with onchanges in sub fields, but
no onchange on main fields. For example, the merge contact wizard.
To solve this issue, we had to propagate the current view type from the
field to the basic model, because otherwise, the main viewtype was used
to compute the onchangeSpec, and that is not always correct.
|
|
Previously, the checkbox was not checked when it was clicked in
editable list view, it only opened the row but did not check the
checkbox.
|
|
Before this commit, only fields which were specializations of the
`InputField` were handling up/right/down/left navigation in editable
list view. As m2o field is not an `InputField` (yet?), it was not
possible to navigate from one of those for example.
Now, navigation events are handled by the `AbstractField` class. If a
given field has to handle navigation a different way, it is its
responsability to stop the associated navigation event. For example,
`InputField` instances are stopping the left/right event if the cursor
is not at the start/end of the <input/> element.
Also, before this commit, there were many events ("move_down",
"move_left", "move_next", ...). Now there is only one event for
navigation: "navigation_move". This event is given a "direction" data
("left", "next", ...). It also comes with a "target" data which is a
reference to the last `AbstractField` instance the navigation event
has crossed.
|
|
The 'get' method in the basic model is called very often (too often, but
that is another issue). For a large list with many columns, it can be
quickly be called more than 10k times.
In that function, we had to protect our integrity by performing a deep
clone with $.extend, so noone else can be allowed to change something in
our internal structure. This is good in theory, but not so good in
practice, as $.extend is a really expensive operation.
Also, we try to have the smallest external API by deleting useless keys.
But instead of keeping a blacklist of private keys, it is simpler to
have a whitelist of public keys.
So, what we do is to explicitely construct the object returned by key,
since we know the types of every values involved. This is more
explicit, and at the same time, much faster.
Also, we propagate the options for elements of type list. This is why I
had to change the isFieldSet method.
In a benchmark I just ran, loading and rendering a large list (200 rows,
7 columns) went from about 2.7s to 0.7s.
We still do way too much work, but at least it is much faster...
|
|
Before this commit, fields were selected on activation (focus) but only
after a setTimeout. This setTimeout is in fact not necessary. Removing
it allows to test the selection in unit tests.
|
|
`DebouncedField` and `InputField` classes were not properly factorized,
some of the DebouncedField code had to be part of the `InputField`
class (which is a specialization of `DebouncedField`). Indeed the
`FieldText` class, specialization of `DebouncedField` class, was missing
properties which were part of `InputField` and was duplicating code
which was already defined in `InputField`.
For example, it was not possible to navigate out of text fields in
editable list views with the right/left keys as this was part of the
`InputField` class.
Note: the FieldTextHtmlSimple class was implementing the `commitChanges`
function differently than `DebouncedField` but this was in fact not
necessary. This is why documentation update has also been done for this
by this commit.
|
|
Since the new views merge, a lot of design elements were broken. This
was particularly impacting the fields in the editable list view; indeed
the editable list view is not using an inline form view anymore so the
fields in the list were not properly styled as the LESS was still
defined assuming the form view environment (for example the invalid
fields were red for o2m fields in form view but not in editable list
view even though they got the right CSS class).
This commit refactor the LESS following these rules:
- No more division of non-layout and layout rules. Dividing LESS rules
in x_layout.less and x.less was a mistake. Many rules can be
considered to be layout and not layout at the same time, developers
always have to switch from one file part to the other, many CSS
selectors (and rules!) are duplicated for nothing, ...
- Field style is extracted from x_view.less and put in the new
fields.less file. As before, the fields_extra.less will contain the
rules specific to community so that the enterprise repo can override
those by replacing the whole file.
- Many classes have been renamed so that o_form_x_y becomes o_x_y as
many classes can now be applied outside of form view. These classes
should not be used in templates anyway.
The commit also changes the DOM of fields so that it is more minimalist
(no useless parent div, etc).
Input elements are not automatically styled anymore, they have to get
the o_input class explicitely. This allows to fix lots of small style
bugs of previous versions (required monetary field had not the proper
style, readonly m2m tags appeared as editable, ...). This also improves
the LESS code.
The editable list view should also completely stop flickering on chrome
and firefox.
The commit also removes the orange outline on list view dirty cells.
The commit also removes deprecated static xml, LESS and other code.
Notice there are still styles to restore/fix and LESS to improve.
|
|
With this commit, we try to improve the way navigation is done in the
list view. In particular, we want to make sure that pressing TAB on the
last editable cell move the cursor to the next line (and create a new
line if necessary).
Also, we add a few tests for keyboard navigation (it was almost not
tested before this commit, and while working on this commit, it was
broken at some point).
|
|
When we unselect a line in a one2many list, we ask for all fields to
commit their changes (because many fields are debounced, so we may not
know their current last value). This is good, except that it could
trigger an extra field change event, which may in turn trigger a second
onchange.
We solve this issue by improving the _setValue method and delegating the
comparison to a new _isSameValue method.
It is particularly relevant for field types such as integer, which are not
stored as a string.
|
|
Since the new views, the editable list view lost some behaviors. These
behaviors were indeed implemented in the form controller/renderer but
as the new editable list view does not use an inline form view, these
behaviors had to be implemented in the basic controller/renderer.
For this to work, the list editable renderer had to be changed as it
was doing work that should be done by the controller.
The problem is even more complex because the x2m fields are using a
list renderer but not a list controller. So moving code from the
renderer to the controller obviously broke the x2m fields. Right now,
the problem is solved by catching renderer events and forwarding new
ones to the form controller (which handles the x2m specifically).
The initial goal of this commit was to share the validation of records
on save. Indeed, the fields were marked as invalid in the form view but
not in the list view. Also, before the new views, the editable list
view had different behaviors if they were used for a x2m field or not.
As these behaviors are making sense, this commit tries to restore them.
Basically, what we want is:
- When a record is saved (form view save or list view line leaving),
the invalid fields are marked (in red), the names of the related fields
are notified to the user and the record is not left.
- When a record is discarded (form view discard or list view discard),
the user is asked to confirm if the record is dirty before making the
record readonly.
- When a record is discarded, if the record is a new one, then the
record should be abandoned (removed as if never existed). In the form
view this induces to go back in the history and in the list view, to
remove a row.
- For x2m fields, the notification of invalid fields is not triggered
but the user is instead asked if he wants to discard the changes made
to the row (indeed, this replaces the list "Discard" button, as non
existent for x2m lists).
- ...
Saving, discarding, marking the fields as invalid and other behaviors
are thus now shared behavior of basic views.
The management of the dirty flag has also been moved to the model
as it was handle by the controller for the form view but by the
renderer for the list view. Now this flag is directly managed in the
basic model (the model can have changes thanks to the `_changes`
property but not be dirty (this is the case for creations)).
This change however created a problem. The view manager is currently
keeping asking if there are changes to discard at each action which
might lead to leave a dirty record (appswitcher / url change / ...).
It however did not discard anything as leaving if the user is ok with
it will lead to an implicit discard. However, as the view manager might
ask for this discard multiple times by second, the controller was
marking the record as not dirty the first time but without discarding
the changes. This is more complex to do now, as the dirty state is
part of the model and that the renderer should match the model data.
To solve this problem, the view manager now actually discard changes
explicitely when asked to. Even though this had been optimized to not
cause any rerender in some cases where it is not needed, this could
cause some performance decreasing. However, this makes some cases more
logical (opening the app switcher on a dirty form view then going back
to the form view by hitting the "go back" button left the form view
untouched although the user asked to discard it). This solution will
be improved with the view manager refactoring.
This commit is also making use of the `commitChanges` system which had
been implemented for HTML fields. Indeed, these fields cannot know
about all of their changes, so when hitting the save button, we asked
those fields to commit their value. Using this system is a great way
to make the `isValid` method of x2m fields synchronous. Indeed, before
this commit, the method was sometimes asking the user if he wants to
discard an invalid line before save. That case can be handled by the
x2m `commitChanges` method: we consider that saving the lines of x2m is
an operation that has to be done before considering the save, so we ask
all the x2m fields to do so at that time. Also, the system was broken
since a recent commit: we indeed protected the changes - save order
with a mutex but unfortunately, the `commitChanges` method was part of
the save and the changes it triggered were not able to be considered
because of this mutex. This had not been detected by tests as there is
not current way to test html fields.
|
|
When a form view switches to edit mode, it is supposed to give the focus
to the first field, or, to a field tagged 'default_focus'.
|
|
Before this commit, when a field was changed, it always triggered a
field_change event, with the new value, even if that value is not valid.
As a result, it could happen that an onchange was sent to the server
with a string as the value of a float field.
What we do in this commit is making sure that invalid values do not
escape the confine of a field, by returning immediately after detecting
that a value is not valid.
|
|
* display a warning when the timezone offset is not the same of the browser
timezone offset
* if different, display the time in the selected timezone
|
|
* 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.
|
|
The field widget html wasn't implemented yet in the new views. A
very basic implementation was done in addon web. It only handled
the readonly mode so that the field were displayed in studio.
This commit removes this basic implementation from web, and re-
introduced the old one, converted, in addon web_editor.
|
