closes odoo/odoo#68085 Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Commit [1] altered the way the FieldMany2Many behaves with respect to 'create' and 'delete' options. Indeed, for many2many fields, adding or removing records doesn't mean "creating" or "deleting" records, as it is only about adding/removing records to/from a relation. This is completely fine and correct. Unfortunately, a feature has been lost in the process: it is no longer possible to state that a many2many field should be editable but should not allow to add (or remove) record to the relation. This commit fixes the issue by adding two new options: 'link' and 'unlink' for that purpose. [1] https://github.com/odoo/odoo/commit/c98579d25af01c14df4baf57fb4652f3e7469096 opw~2466213 closes odoo/odoo#67358 Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The Many2ManyCheckboxes widget displays all values that could be in the many2many relation, with a checkbox indicating whether each value is in the relation or not. It is designed to be set on fields where the comodel contains a few records (typically, we don't want to see dozens of checkboxes in the form view). This widget shouldn't be used on many2manys with a large comodel, as we have better tools to handle them (like a tree view). We deal with extreme cases (when the widget is, by mistake, set on a field where the comodel is huge) by using the name_search limit of 100: at most 100 checkboxes are displayed. Before this commit, this extreme situation wasn't correctly handled. If there were in the relation records that weren't displayed (because they weren't inside the 100 limit), then, editing the value by (un)selecting a checkbox would automatically remove all non displayed values from the relation. This commit ensures that we keep in the relation all values that aren't displayed. Issue spotted when working on opw~2439041 closes odoo/odoo#67373 X-original-commit: fa324ef071952d749f635f878bee0fa462cfa011 Signed-off-by: Géry Debongnie (ged) <ged@openerp.com> Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, if the widget "many2many_checkboxes" was set on a field with more than 40 values in the comodel (i.e. more than 40 checkboxes displayed), (un)selecting a checkbox that wasn't in the first 40 checkboxes crashed. This was due to the default x2many limit of 40: we only created a datapoint for the first 40 values, whereas we could have up to 100 values to process (name_search server-side limit). Note that this limit of 40 had no other impact than limitating the number of records processed by the BasicModel, the maximum number of checkboxes displayed being ruled by the name_search server-side limit. This commit ensures that all values returned by the server (at most 100 when this message is written) are processed and can be edited as expected. opw~2439041 X-original-commit: be5e5bc49cb9744c26ca75dcee74caf11447f250
Commit [1] adds an override of the getFocusableElement of AbstractField in FieldRadio, but this function was already defined. Even though it doesn't crash, this is obviously not something to do. This commit removes the first occurence (which was overriden by the second). [1] https://github.com/odoo/odoo/commit/ebe118fc607391737adc37e18c3278a3d2c87b5e closes odoo/odoo#65372 Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Let's assume the following scenario with 'purchase_product_matrix' module installed: - create a new Purchase Order - add a line in the one2many - select "Customizable desk" as product - [the desk matrix opens] - close the matrix - select "Conference chair" instead - [the desk matrix opens, whereas it should be the chair one] It didn't work because of a small bug in the FieldOne2Many. This field is configured to be reset when any other field in the view changes. The product configurator feature relies on that. However, when another field changes, the One2Many didn't update its internal state with the new record (and it skipped the rendering, which is fine). The matrix product configurator thus read an obsolete value in the internal of the one2many. Since the internal state is now always up-to-date, we can directly read there the grid information, instead of looking inside other fields that have been updated (attempt done in [1]) It would be nice to rethink the whole product configurator stuff in master, to make it more robust, maybe when converting it to owl? [1] https://github.com/odoo/odoo/commit/21bcafc053be7f80eed7a684fee2dc1e3caaafa5 opw~2421798 closes odoo/odoo#64552 Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
The ControlPanel has been converted in Owl [1], and the code using
it has been adapted accordingly. However, in the FieldX2Many, we
didn't properly wait for the ControlPanel to be updated (an update
of the ControlPanel was synchronous before owl, and is now async,
like every Owl renderings, as it waits for the nextAnimationFrame).
As a consequence, we might have tricky issues because the mounted
hook of the control panel might be called multiple times for a
single call to willUnmount later on. In mobile, we bind a global
event handler (on scroll) in mounted, and unbind it in willUnmount,
so we had leftover event handlers, that crashed when called after
the ControlPanel was destroyed. Note that even if the issue popped
in mobile, calling mounted on already mounted Components isn't a
good idea, and this should be fixed anyway.
The issue could be reproduced for instance in FieldService (with
collaborative pads activated in Project), in mobile, by opening
a task in Edit mode. Then, you might get a traceback by scrolling
after having discarded the edition
Here is a description of what technically happened:
- when clicking on Edit, all widgets (including the FieldX2Many
are destroyed and re-instantiated in 'edit' mode).
- the pad widget directly triggers a field_changed event which
causes a reset of the FieldX2Many (i.e. 'render' is called
again)
- the FieldX2Many detects that it already has a renderer (and a
ControlPanel) so it updates them
- it first updates the renderer, and when it's done, it updates
the ControlPanel BUT doesn't wait for its promise, so the
promise returned by that call to 'render' in FieldX2Many is
resolved before the ControlPanel is actually updated
- note that at this point, all thoses new widgets are not in the
DOM yet
- when all widgets are ready, the renderer patches the view (i.e.
the former content is removed from the DOM, and the new one is
attached into the DOM). As soon as this is done, the renderer
calls 'on_attach_callback' on its children, including the
FieldX2Many, which leads to a call to 'mounted' on the CP.
- then, just before the nextAnimationFrame, Owl complete the
rendering of the CP, and detects that it is now in the DOM (it
wasn't at the beginning), so 'mounted' is called a second time,
will cause the issue described above.
This commit fixes the issue by properly waiting for the CP to be
rendered in the FieldX2Many. However, this required on cascade
changes:
- Form view renderings with a FieldX2Many are now *really* async
(+- 16ms), meaning that the user can easily trigger concurrent
renderings by, e.g. clicking quickly several times on 'Edit',
'Save' or 'Discard'. Concurrent renderings are properly handled
so to prevent this from happening, we disable the buttons and
re-enable them when the rendering is done (like already done in
[2])
- in the FieldX2Many, '_updateControlPanel' was called at several
placed, but we never waited for it. As this method was
originally sync, its calls have probably been naively adapted,
whereas their should have been deeply rethought (for instance,
as it is async, and we need to wait for it, we don't want it
to be called multiple times sequentially when something happens).
This commit does that work, i.e. we clean the places where this
function is called such that it is (hopefully) never called
sequentially twice. To do so, we changed a bit the spec of the
pager in multi page, and we also fixed a paging-related bug.
In a few words, here is what we did/do when adding a new row
in the bottom of a full page:
- before: tweak the count in the data to fool the pager and
make it think that no new record has been added (so
basically, let it display something wrong)
- now: temporarily increase the pager limit so that the new
record is displayed on the current pager, and the pager
values are correct w.r.t. the displayed records.
Some tests needed to be adapted accordingly.
- By waiting for the ControlPanel when updating the FieldX2Many,
a bunch of QUnit tests failed. Those tests have something in
common: they spawn an X2Many (list or kanban theoretically,
but always list in practice) containing a FieldBoolean (only
field widget of /web converted in owl). When the FieldX2Many
is updated, we update the renderer (i.e. re-renderer the
FieldBoolean, so we have to wait for the nextAnimationFrame),
and when this is done, we update the page (again, we have
to wait for the nextAnimationFrame). So basically, we have
to wait for two nextAnimationFrames to see the result in the
DOM. For this, we added a new test util which basically does
a nextTick ('owlCompatibilityNextTick'), and called it
everywhere it was necessary. When everything will be written
in Owl, we could get rid of this util and its calls.
[1] https://github.com/odoo/odoo/commit/fbf347498f1cc7b74ef373179b7bcae201715c24
[2] https://github.com/odoo/odoo/commit/39f08950d6e20460e3a20a5b9c33e4ddf66dce78
closes odoo/odoo#61593
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
When navigating fields using the keyboard, it's not possible to reach most of widgets for selection fields. That is because most of them consist of one main element containing several other ones, one per possible selectable value (e.g. buttons). When their focusable element is computed, the main element is taken, instead of its sub-elements, which causes the field to be skipped when navigating. This commit fixes the above, as well as some missing aria attributes and keyboard events, for the following widgets: - `priority` - `state_selection` - `statusbar` - `radio` opw-231112 closes #58302 closes odoo/odoo#58418 X-original-commit: 2471e7c176c5df0f310f2939f8a6cf6948c0ac0c Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Task 2327599 It is used in the selector of a tour to know the type of a document.
Currently, when form view is opened in edit mode and if you proceed through the tab(keyboard) then focus is skiped on radio field. For Ex: in project when you procceed through the tab it will skip the visibility field radio. The issue occurs because the radio is inherited from the selection field and in selection field the focus is set on 'select' while there is no method to set the focus in radio and radio does not have 'select' element it has 'input' So in this commit, override the method getFocusableElement in radio widget and set the focus on 'input' instead of 'select'. closes odoo/odoo#52073 Taskid: 2252798 Closes: #52073 Related: odoo/upgrade#1430 Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>