| Age | Commit message (Collapse) | Author |
|---|
|
Before this fix, in form view, when a datepicker was not visible (because
they were on another page or literally invisible), when the user pressed
TAB and the datepicker was positionned after the current field in the
form, it was capturing the focus during the activate phase of the
navigation_move.
This is not correct for invisible elements.
After this fix, only focusable datepickers get the focus during the
activation phase of the navigation_move.
co-author: aab-odoo (aab@odoo.com)
|
|
Purpose
=======
The 'CREATE' operation lacked the possibility to handle multiple records.
The 'context' parameter is now an array of dict that contains the context for each new record.
This is usefull when you want to create multiple records into a list in a single call.
Please note that the 'default_get' is still called once for each record in an async way.
|
|
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
|
|
This commit fixes a few issues with the previous implementation of the
automatic addition of new lines in x2many inside forms
1. Before this commit, when there is a change of mode in a formview
`edit` -> `readonly` -> `edit`, there may be some cases that
mistakenly and automatically opens a modal.
This case occurs in a form view with a x2many field whose 1st inner
focusable element opens a modal (e.g. "Add an item").
In `edit` mode:
1. Open this modal from the x2many
2. Close the modal
3. Change mode to `readonly`
4. Change mode to `edit`
> the same modal is automatically open.
This is due to the tracking of the last activated field that persists
after a change of mode. Since the last activated field in the 1st
`edit` is the x2many, it is granted the focus at the beginning of the
2nd `edit`, which automatically opens the modal.
This commit fixes the issue by resetting the tracking of the last
activated field when there is a change of mode. As a result, at the
beginning of the 2nd `edit`, the focus should always be on the 1st
field.
2. Before this commit, if the focus was moved out of the form (to a modal
for instance) then back, the form would re-activate the last field, which
is the x2many and would re-add a new line. This behavior is not correct
and now going back from a modal to a form does not add a new line.
Co-authored-by: Alexandre Kühn <aku@odoo.com>
|
|
Before this change, when the focus was on the first field on a x2many
field, and the user pressed TAB, the line would be discarded and the
focus moved to the next field (at the level of the x2many) in the form.
This was an issue because if the first field was required, the focus
could not be moved out of the field with TAB so the user had to discard
the line manually (with ESC) before moving to the next field
This change works with 2 changes:
1. detecting if a line is dirty (has been modified by the user) and at
the end of the line, decide to either
- discard the line and move the next field, if the line is not dirty
- commit the line and add a new line, if the line is dirty
2. allow users to use TAB through required field inside x2many so they
can easilly go to the end of the line.
Task id : 1872248
|
|
For Name field or M2O, gives a list of companies
Data comes from Odoo IAP Service
|
|
|
|
|
|
|
|
The datepicker lib has been updated to tempus dominus (BS4)
recently, but our code hasn't been adapted correctly to the
requirements of the new version of the lib. As a consequence,
the datepicker didn't close itself when the input was focused
out anymore.
This required a slight change in the DomainSelector widget as it
produced a crash when a focused datepicker widget is removed from
the DOM (before the datepicker is destroyed), e.g. by a call to
html() on one of its parent.
Task 1878254
|
|
This rev. is similar to db9b91ff, but treats the x2many case.
Calls to the 'commitChange' function of renderers must not be done
inside a mutex, mainly since 241704536, as they could end up in a
deadlock. For x2manys, it was actually the case in practice in
Inventory > Operations > Inventory Adjustments > Create > select
'One product only' > select a product > try to edit the real
quantity in the editable list > focusout > deadlock.
The reason why the deadlock occurred in this view and not in, e.g.
sale.order, is due to the presence of the field_float_scannable
widget. Indeed, the barcode engine intercepts input events and
manually re-triggers them. As a consequence, the 'change' event is
not triggered on the field, and it does not notify the environment
of its new value by itself, until the field x2many asks it to
commit its value. Note that this might be an issue as well, as
onchanges are thus not triggered.
Task 1878254
|
|
Rev. f241441 recently added the possibiliy to define custom
controls (instead of the single 'Add a line') in editable list
views. However, it didn't take into account keyboard navigation.
Suppose that the focus is on the field preceeding the list, and
the user clicks on TAB, the code assumed that there was only one
control, and focused it. However, when there were several control,
the last one was focused (which is typically the less common one),
and there was no way to navigate to the others.
This rev. focuses the first control by default, and allows to
navigate through controls with RIGHT and LEFT. Pressing TAB still
moves out of the list, to the next field.
Note that i'm not happy with this fix, as the logic doesn't seem
to be in the right place. Indeed, the notion of controls is the
concern of the editable list, not the x2many field, so the list
should handle this logic by itself. Unfortenately, this is not that
easy to change, as for now the list doesn't even know that we are
navigating to/from its control(s), until we click on it/them.
Changing that will be for later, in master.
We also did a linting pass on the concerned code.
Task 1878254
|
|
Hardening of commit:995610c065bf0242cb5023cfad2940234395739e
The JournalDashboardGraph requires nv, which is lazyloaded.
However it requires nvd3.js which is loaded after nv.d3.js.
A function called in destroy is defined by nv.d3.js,
which can make the crashhappen with the right (wrong) timing.
opw 1873749
|
|
Before this rev., if the user clicked on a tag to open the color
picker, and then clicked in the dropdown, but not on a color, the
color picker closed itself, and it was no longer possible to open
it again.
This issue came with the migration to BS4 and its following fixes.
As the color picker is now a classical BS dropdown, it closes
itself automatically, so we don't need to manually close it on
focusout.
Task 1878254.
|
|
|
|
This allow the browser/device to handle the experience of handling number in a more native way.
FieldInteger and FieldFloat now inherits from NumericField because we want
to format it or not dependent of the view (readonly or edit) and the
NumericField will manage it.
We do that because input type number can't take a value with comma on Chrome
(FireFox is more permissive but not perfect because comma is the separator
for decimal in this case).
Task #1880376
|
|
|
|
|
|
This rev. removes a deadlock situation that could *theoretically*
occur, but that was actually hard to reach in practice.
Before saving a record (e.g. in a form view), all field widgets
are asked to commit their value (in case they wouldn't have
notified the model yet, e.g. because the user just changed them).
For instance, let's assume that the user fills an input field, and
then triggers the save. In practice, by triggering the save, it
will force the widget to notify the model of its new value (because
it looses the focus). This is also the case using keyboard
navigation, as it actually simulates clicks. So when the widget is
asked to commit its value right after, it has nothing more to
commit.
This is fortunate, because if it actually had something to commit,
we would end up in a deadlock ('commitChanges' is executed in a
mutex, and if the widget triggers a new value, '_applyChange' is
called, and is executed in that mutex as well). In fact, executing
'commitChanges' in a mutex is useless, as '_applyChange', which is
called when a widget has something to commit, is already executed
in the mutex.
So this rev. removes the use of the mutex in 'commitChanges'.
Doing so broke several Many2One tests, because they wrongly relied
on the presence of the mutex for scenarios where the user quick
creates a relational record, and then directly saves (before the
relational record is actually created). We thus handled that
usecase properly to make the tests pass.
Task 1878254.
|
|
Suppose you select a customer for a sale order.
You type the beginning of his name "think", and a name_search is triggered
which finds matching results, with first result "Think Big Systems".
There are three ways to select it: click, enter or tab.
Now there can be a warning set on this customer
("Bad client, only accept cash", or "good client, offer discount").
In that case, clicking on tab would trigger the onchange displaying the warning,
but it would also set floating to true, which means a dialog to create client
"think" would appear.
This happens if the onchange is delayed, and thus the call to reset the floating
state is triggered only after the focusout completed, instead of before.
Coauthored with @aab-odoo
opw 1866619
opw 1874475
|
|
The domain was instantiated without being given any evaluation context.
As a result, the uid variable was not defined,
crashing the js if present in a user-defined filter.
opw 1866852
|
|
momentjs `isSame` method considers undefined values but not false
our method _isSameValue does consider false
Correct the error when running web tests
Deprecation warning: value provided is not in a recognized ISO format
|
|
289adeb63f51a9af26b8f383ba80089aa7aa6d87 introduced a bug where we tried to trigger an event on an element that didn't exist. Indeed there is no input if it's not in edit mode.
This commit fixes it.
PR: none
Task: none
|
|
* mail, calendar
- Fix traceback when clicking on a tag without color field (introduced
in recent changes)
- Properly allow to delete tags on firefox (a button obviously cannot
contain another button)
Closes https://github.com/odoo/odoo/pull/26547
Thanks to @hbh-odoo
|
|
Since in hr_timesheet, we are binding 'timesheet_uom' widget
on existing one (and it might change according to the session
info), we came to the case a formatType is different from the
one of the widget in the registry. Then, the AbstractField
fallbacks on the field type as formatter. Example;
timesheet_uom widget is blind on float_time, but their keys
are differents in field registry, so the formatter will be
'float' and not 'float_time'.
This commit override the formatType determined by the
AbstractField for the float_time widget.
|
|
Take advantage of the new BS4 checkbox structure to simplify the
widget too.
|
|
Before this commit, a textarea would not resize when its value changed if the event was different than "input" or "focus".
This commit fixes it by also listening to the "change" event, and by triggering it at appropriate times.
PR: #26430
Task: 1869469
|
|
In a one2many, pressing ENTER or TAB from a required input (of type text or char) that is on the last editable column of its line would fail to navigate to next line.
The issue was that the validation of the required field would happen before the change to its value was actually applied.
This commit fixes it.
PR: #26430
Task: 1869469
|
|
Bug revealed with BS4.
|
|
Currently, to remove link of x2m field from any record, sometimes there's no way.
For example, if we are on mobile and open any Quotation, it's linked quotation lines
are automatically converted in kanban, and there is no way to delete a line from
that quotation. However, in some of the manually designed kanban, there is special 'x'
for removing / unlinking x2m record, for example, Contacts of Partner.
This commit makes the behavior more consistent. During edition (mobile and desktop), if
a view dialog is opened on click of x2m field, it will have one 'Remove' button (based
on user rights) on right side of dialog footer, allowing users to delete / unlink the
record. Moreover, in mobile, the modal is opened fullscreen, with sticky header and
footer.
Related Task# : 31641
Closes PR #15857
Co-authored-by: Mohammed Shekha <msh@openerp.com>
|
|
example: <field name="product_id" options="{'no_open': True}" readonly="1"/>
This has been broken by rev. 43d21dd9c due to misplaced parentheses
(an empty object in javascript being truthy).
|
|
The lib 'nvd3' renders graph when they are attached to the
DOM. However, widgets are rendered in fragments and
appended to the DOM when ready (to prevent flickering).
Before this commit, we used a `setTimeout(0)` and cross
fingers that the widget was attached to the DOM when the
`render` method was called.
With this commit, the render method is called when it is
attached to the DOM.
Task-ID 1868252
Closes #26410
|
|
When paced inside the i tag, the text used to inherit from the
style of the star, which means the text was yellow when starred.
|
|
This adds a button to import several bills from the accounting dashboard: will create a new vendor bill for each, with the file attached to it. That file will be visible in the chatter (in enterprise) and allow easilly completion/encoding of it. This task also comes along with the import/export of xml files attached to the PDF files created from the invoice report.
Was task 1859277
Was PR #26339
|
|
From this rev., the empty value isn't available in the options of
required selection fields, thus preventing the user to unset it.
Related to task #49262
Closes #24404
|
|
Before this rev. one could set the report layout on the company using a
hardcoded list (background, clean, standard, etc.). Other modules (typically
accounting modules) could add options in this list. The used template was built
on the layout key.
Now, the layout is a many2one field to a newly created model `report.layout`,
which is linked to a view with the layout architecture.
This gives more control to customize reports and create a new layout (without
creating a python module that extend the layout selection).
|
|
The FieldMany2ManyTags uses FieldMany2One in its implementation.
Before this commit, the field attributes were not propagated to the sub field.
In particular, the attribute `can_create` is useful to be propagated.
|
|
This commit provides new js widgets for list, kanban and form
views on float field.
1/ 'float_factor' displays the normal float field, but takes a
conversion factor as option. The displays value is the normal
one multiplied by the factor.
You can use the widget like
<field name="my_float_field" widget="float_factor"
option="{'factor': 2}"/>
2/ 'float_toggle' displays a button (in edit mode) looping on a
range of given value at each click. A conversion factor is optional
(default will be 1) to display a converted value, but sent to
non converted one to the server.
You can use the widget like
<field name="my_float" widget="float_toggle"
option="{'range': [0, 0.5, 1], 'factor': 2}"/>
'range' and 'factor' are put in the options.
In simple read mode, the widget display the value as a traditionnal
text (like a normal char field).
This commit provides tests and documentation for those 2 widgets.
Task #39079
|
|
This rev. allows to instantiate a FieldMany2one Widget with option
'noOpen' (which hides the external button allowing to open the
related record in a dialog).
This option already existed, but it had to be specified in the
nodeOptions (i.e. in the view arch), which is not convenient for
standalone fields for which there is no view.
Part of task 1853490
|
|
Purpose
=======
If the model on a reference fields is not modified from the interface
by the user but by the server, the selection is not correctly
recomputed on the interface.
Specification
=============
By calling super first on the '_reset' method, the new model
is taken into account when resetting the selection.
|
|
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
|
|
Since Bootstrap 4, ClipboardJS does not copy the value in the clipboard anymore
as Bootstraps modals give the focus to another element. As the focus need to be
given back to the correct element, ClipboardJS has to be updated as the
container parameter is only added in v1.7. We were in 1.5.
That container parameter allow to give the focus back to the correct element.
See doc on https://clipboardjs.com/
+ Issue : https://github.com/zenorocha/clipboard.js/issues/155
|
|
|
|
|
|
Revision on https://github.com/odoo/odoo/commit/4b3588feb2b7e260bf237b0f3944c90cdc47c3b5
In order to not replace characters with '*' in edit mode (because of `input`
with type 'password'), the above commit did not format the value at all.
The formatter of a char with the option 'isPassword' turns all of its
characters into '*'. That is not intended for password inputs, because the
content is hidden by the browser with the 'password' type.
The issue with not using the formatter is that an empty field has the value
`false`, so an empty password field produces an non-empty password input with
its value to 'false'.
This commit fixes the issue by forcing empty string for empty password values.
Note: if you use an integer field with password, falsy values (e.g. `0`) become
empty strings in the input value.
|
|
Before this commit, when someone was editing a password, the stored
password may not be the expected one by the user.
Steps to reproduce:
1. Open "Outgoing Mail Servers" form.
2. Set a password (e.g. "yop").
3. Save, then edit.
4. Add "y" at the end of the password field.
> Expected value: "yopy"
> Actual value: "***y"
This is due to the use of the char field formatter, which displays passwords
by replacing the characters with '*'. It is not necessary to do this in edit
mode, because it uses an input field of type 'password'. The browser
automatically hides the value of such inputs.
Any changes on a input field in edit mode uses the value of the input, so the
value of an password input should contain the password, without '*'.
This commit fixes the issue by using the formatter in edit mode for the input
of type 'password'.
Task-ID 1869565
|
|
The '.label' elements have been replaced by '.badge' elements without
the 'badge-pill' class.
|
|
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)
|
|
col-lg-* -> col-xl-*
col-md-* -> col-lg-*
col-sm-* -> col-md-*
col-xs-* -> col-*
col-lg-offset-* -> offset-xl-*
col-md-offset-* -> offset-lg-*
col-sm-offset-* -> offset-md-*
col-xs-offset-* -> offset-*
col-lg-pull-* -> order-xl-1
col-md-pull-* -> order-lg-1
col-sm-pull-* -> order-md-1
col-xs-pull-* -> order-1
col-lg-push-* -> order-xl-2
col-md-push-* -> order-lg-2
col-sm-push-* -> order-md-2
col-xs-push-* -> order-2
|
|
|
