This is a weird situation, but the python handles it. Let's assume
a many2one field F1 on model M1 with comodel M2, and on M2 the name
field (which is the _rec_name) being itself a many2one, and the
following scenario:
- create a new record for M1
- for field F1, select 'Create and Edit': it opens a form view for
M2 in a dialog
- type something in F2 input, and click 'Quick create'
- save the dialog
Before this rev., the value of F1 was [object Object]. Now, the new
value is properly displayed.
OPW 2091106
closesodoo/odoo#40549
X-original-commit: 5a04ea848abf50b1fb1f9893d1fcd98013bc025d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, all the computation of the default widths for column
headers was done before the list was attached to the DOM, meaning that no
column was actually visible. This was a problem since columns that are
meant to stay unseen were taken into account in the calculation of relative
column widths.
Now, the same algorithm runs once the columns are visible so that invisible
columns can be properly excluded.
fixes#38744
Task 2076721
X-original-commit: 4bf98b47898b075049975dfe597f0fb92c7c14d1
Purpose
=======
We want to add an option on the widgets
- many2many_binary,
- binary,
- image
This option specifies what file extensions the user can pick from the file input dialog box.
Examples
========
```xml
<field widget="many2many_binary" options="{'accepted_file_extensions': 'image/*'}"/>
<field widget="many2many_binary" options="{'accepted_file_extensions': '.png,.jpeg'}"/>
<field widget="many2many_binary" options="{'accepted_file_extensions': 'application/pdf'}"/>
<field widget="image" options="{'accepted_file_extensions': '.png,.jpeg'}"/>
<field widget="binary" options="{'accepted_file_extensions': '.pdf,.svg'}"/>
```
How
===
Add an option (accepted_file_extensions) in the template ``HiddenInputFile`` (the widget many2many_binary is using this template)
So, we can also use this new option in others widgets using ``HiddenInputFile``
In the many2many_binary, read the ``nodeOptions`` and set the widget attribute ``accepted_file_extensions``
We also have to fix some other widget, because an property ``image_only`` was already existing in the template ``HiddenInputFile``
(we just need to replace ``image_only=True`` to ``accepted_file_extensions='image/*'``
The widget ``FieldPdfViewer`` (pdf_viewer) now use the new option to filtrate PDF
(instead of removing the <input/> and adding <input accept='.pdf'/>).
Tests
=====
We also test if the option is correctly set on the <input/>
- binary
- image
- many2many_binary
Impacted widgets
===============
- many2many_binary
- image: this widget use ``options="{accepted_file_extensions='image/*'}"`` instead of ``image_only=True``
- tablet_image: same as ``image``
Task #2082815closesodoo/odoo#38351
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
This option, if set to True, prevents the user from modifying the
color of the tags.
Part of task 2070454
closesodoo/odoo#38848
X-original-commit: a62b65a8f9114493064d4efae92825814a880c04
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
-Import a subscription with end date beyond 200 in the future (ex: 2500-01-01).
-Open the subscription and click the Edit button.
Before this commit:
A stacktrace appears indicating that a date is not valid. It's not possible to
edit the subscription.
After this commit:
The maxDate of the date picker has been increased to 31/12/9999, allowing the
user to edit subscriptions whose end date is that far in the future.
A test `toggle datepicker far in the future` for this case has been created.
closesodoo/odoo#38527
Opw: 2079696
X-original-commit: 32b6131c04fef7a542a0ccbdb924d177627bfe38
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Backport of 64f6e50d0c, with a test!
Closes#27109
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.
closesodoo/odoo#38109
X-original-commit: b5b992d9c4e85c224ded795ff9ce14d1608b3ed6
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Changes the behaviour of many2ones when their value is changed via a form dialog.
Before this commit, when editing a m2o with a form dialog opened by an external button,
the field triggered an onchange with its old value before reloading its widget.
This caused the edition in list views to display outdated information when
saving multiple records.
Now, the reload is executed first, then the onchange occurs so that the value is
the newly updated one.
Part of task 2078807
closesodoo/odoo#37576
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
only activate multi-edit on list with specific attribute.
When the attribute multi_edit="1" is set on the tree view the user
can select a/some records and it will activate the multi-edit
with confirmation dialog (even for a single record).
Also, on-change are not applied when using multi-edit
closesodoo/odoo#37525
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.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.
closesodoo/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>
ClassNames 'oe_read_only' (resp. 'oe_edit_only') can be used in
x2many lists to hide columns in 'edit' (resp. 'readonly') modes.
However, before this rev., there were two issues:
1) Having such a className on a <button> tag didn't work well as
the 'display: none' rule didn't apply on the body cell (it only
applied on the button). Same could be observed on <widget>
nodes.
2) Having more than one invisible column (with those classNames)
didn't work either, because the footer cells weren't hidden.
We didn't notice it with one invisible column, because the
footer contained one cell less than the header and the body.
Those two issues could be observed on the mrp.bom form view.
Task 2068261
This commit fixes:
- body of a email.template in a small field
- translation of website_description of a product does not show the
source of the translation
- translation of website_description of a product shows the full
content for the current language
HTML fields are typically fields with longer of content.
If the field is an HTML field, it should be displayed in a textarea,
like the text fields.
Most of HTML fields are split in meaningful chunks of content (using
xml_translate or html_translate method).
For these fields, the source must be displayed.
Also sort the entries on the source to have a consistent order
closesodoo/odoo#37215
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
From the settings activate:
- Multiple Sales Prices per Product
-- Prices computed from formulas
- Discounts
Create a pricelist with discount policy "Show public price & discount to
the customer", set the price calculation formula:
- Rounding: 10
- Price discount: 10%
Modify the sale order xml list view adding 'digits="[3, 2]"' to the
discount shown in the sale order line.
Create a sale order with such pricelist and on the so line put a
product with quantity 1 and sale price 4190 (VAT 19% included in the price).
The discount will not display the requested number of decimal digits (2)
in list view, but it will when editing the field.
The cell formatting is done calling the appropriate function (formatFloat),
which search the digits option from the 'options' parameter or from the field
definition. The latter stores the default digits coming from
the DecimalAccuracy settings, which, as side effect, alter the behavior
of the discount calculation.
https://www.odoo.com/web#view_type=form&model=project.task&id=2069939&active_id=2069939
When passing into edit mode the field is created as widget, parsing its options
which have 'digits', instead when coming back in list mode it is "just a
float field" rendered directly from the list_renderer which no options,
so the formatFloat will look at the field definition
https://github.com/odoo/odoo/blob/12.0/addons/web/static/src/js/fields/field_utils.js#L172
Adding the correct parameter to the dictionary passed to formatFloat
during the list rendering is a possible solution, because it is the
"closest" point in which parsing the parameter is possible without
touching higher level code or forcing the creation of a widget (adding
widget='float' as xml parameter).
closesodoo/odoo#37167
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Since fbbfa6d it's not longer possible
to write a date without separator (e.g., 0102 for 01/02/2019; 121298 for
12/12/1998; 02042018 for 02/04/2018), or a date without year (e.g.,
01/02 for 01/02/2019) in the datepicker widget.
In this commit we have decided to be as permissive as tempus dominus
that call moment.js with strict false. This allows moment.js to deduct a
date from a string in a more versatile way. This also allows a more
versatile autocomplete in the search views.
opw-2070464
opw-2070931
closesodoo/odoo#37095
Forward-port-of: odoo/odoo#36821
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Gives time to the user to enter an actual value in m2o in list views.
Before this commit, emptying a many2one field (selecting all > BACKSPACE or DELETE)
triggered instantly a field_change. This was an issue in multi edition as a field
changed triggered instantly a save on selected records without giving time to the
user to enter a new value.
Now, many2ones only trigger a fieldChange when selecting a new valid value.
The Date(Time)Fields listen to 'input' and 'change' events (like
all InputFields) to keep track of changes. However, the datepicker
already listens to the 'change' event. As a consequence, in multi
edition in a list view, if the user changed the value of a
date(time) field by directly editing the input, the fieldChanged
event was triggered twice, and there were 2 dialogs asking the user
if he wanted to save the change.
This rev. makes the Date(Time)Fields stop listening themselves to
'input' and 'change' events, and instead completely rely on the
datepicker widget.
Task 2068280
Before this rev., the 'fieldChanged' event was triggered each time
the user selected a value (a day, an hour, a minute or a second) in
the datepicker. This means that if there was an onchange on the
field, a lot of RPCs could have been done when a user set a
datetime. In addition, in a list view with multi edition, the user
was asked to save the changes at each step of the datetime
selection, making the feature unusable.
Task 2068280
The progress bar was pretty broken before this commit.
> It was not possible to input the value as text
> Moving the progress bar to modify value and saving crashed
> modifying the max value crashed
> The whole feature was ill-defined
With this commit, we fix the crashed. It is now possible to write the field
behind the progress bar by moving it in RO mode
or by typing the input in RW mode
*if it is the value we want to write on*
It it is the max value that the field targets, we can do it in RO and RW mode,
only with the input as text
Note that this works *only if* the editable option on the widget is set to true
OPW 2061846
closesodoo/odoo#36928closesodoo/odoo#36970
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The FieldColor widget had been designed exclusively for the document
layout configurator. Because of this, the widget would not display/behave
correctly in other views.
Before this commit:
- in list views, the widget had a "white-space" attribute adapted for char fields,
which gave it much more space than it needed
- there was no handling of the widget in readonly state: it was always editable
- its size in list views was a bit too large
Now:
- all styling problems have been adjusted for list views (unchanged for forms)
- the widget is disabled when in readonly mode
Task 2072466
closesodoo/odoo#36949
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
There are too many image sizes. Since they are stored resized this takes time to
generate when saving a new image, it's more rows on the attachment table, more
files on the disk, ...
64px is close enough to 128px that it can be removed without a big impact on
download size.
It will even reduce download and number of requests when both images are
displayed because now only one has to be downloaded and then benefit from cache.
The difference between the two is typically around 1.5kB which is negligible
these days, especially when the request overhead is around 0.5kB already, not
even taking into account other factors such as latency.
If a 64px image must absolutely be returned, it is still possible to pass the
size parameters to the image route. But the current guideline is to handle
resizing in the views when necessary.
Views
=====
- remove width and height attributes when existing CSS rules are overriding them
(eg. `.oe_kanban_avatar` in the right context)
- add CSS rules instead of width and height attributes when possible
- use `object-fit: cover;` where width and height are forced to avoid distortion
of non-square images
- for products, use `object-fit: contain;` instead, keep ratio but without crop
- add new CSS rules where the expected size was max 64px*64px before due to the
image size itself
- remove `img-fluid` where using size classes to avoid conflicting rules
task-2060865
closesodoo/odoo#36147
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
PURPOSE
Previously when the 'SAVE & NEW' button was pressed in the 'create and
edit...' menu of the many2many_tags widget was pressed, the modal window
would close and the button would act exactly like the 'SAVE & CLOSE'
button. This was due to the fact that whenever a new record was created
and added to the field, it would reset the many2one field it uses for
display, which would destroy the edit modal.
This commit fixes that by not notifying the underlying many2one field of
any change until the modal is closed by the user. This has the
disadvantage that tags display, if visible behind the modal 'shade',
will not be updated until the modal is closed, but restores the
functionality of the save&new button. It also adds a test for this
behaviour
task-2070454
closesodoo/odoo#37114
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Gives time to the user to enter an actual value in m2o in list views.
Before this commit, emptying a many2one field (selecting all > BACKSPACE or DELETE)
triggered instantly a field_change. This was an issue in multi edition as a field
changed triggered instantly a save on selected records without giving time to the
user to enter a new value.
Now, many2ones only trigger a fieldChange when selecting a new valid value.
Task 2068280
The Date(Time)Fields listen to 'input' and 'change' events (like
all InputFields) to keep track of changes. However, the datepicker
already listens to the 'change' event. As a consequence, in multi
edition in a list view, if the user changed the value of a
date(time) field by directly editing the input, the fieldChanged
event was triggered twice, and there were 2 dialogs asking the user
if he wanted to save the change.
This rev. makes the Date(Time)Fields stop listening themselves to
'input' and 'change' events, and instead completely rely on the
datepicker widget.
Task 2068280
Before this rev., the 'fieldChanged' event was triggered each time
the user selected a value (a day, an hour, a minute or a second) in
the datepicker. This means that if there was an onchange on the
field, a lot of RPCs could have been done when a user set a
datetime. In addition, in a list view with multi edition, the user
was asked to save the changes at each step of the datetime
selection, making the feature unusable.
Task 2068280
Before this commit, translations were edited in a list view with a filter
on the field that needed to be translated.
After this commit, the translations for each fields are translated in a
dedicated dialog. The changes done to the current language are taken
into account immediately, both ways, from the dialog to the form and
from the form to the dialog.
Translating terms is also available in create mode, the user will be
prompted to save before editing a translation
Task ID: 2028152
closesodoo/odoo#36185
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
The ColorPickerDialog lazyloads its template. In the test
environment, nothing was done (except for a single nextTick) to
ensure that the template has been loaded before interacting with
the dialog. This led to non deterministic failing runbot builds.
Also correctly load the signature template before running its tests
instead of doing two chelou nextTick();
closesodoo/odoo#36511
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
There is an open issue on the tempusdominus lib:
https://github.com/tempusdominus/bootstrap-4/issues/223
It occurs when there is a valid value in a date(time) field, and
the user unsets it by setting an invalid one.
This rev. fixes the issue in Odoo by preventing to reach the buggy
piece of code in the lib. In a few words, when the user sets an
invalid date, we reset the previous valid date (which is what the
lib tries to do anyway).
Task 2057009
closesodoo/odoo#36211
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Before this commit, a field selection which was required
did not have an empty option
ref: 4dfabb8f7a
This is fine, but overlooked the fact that modules can modify
the required attribute, or even views can do it
So, we may end up in a situation where the field is required but set to false
This configuration is problematic, at least for the timezone selection field
(see OPW)
After this commit, the empty option is just not visible
note that `disabled = True` would not work because val is not accessible
Because of commits:
- 4dfabb8f7a for the selection feature
- d77ce4c2a9 overriding the required attribute of tz in res.user form
OPW 2057913
closesodoo/odoo#35989
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The tests in the file `relational_fields_mobile_tests.js` - which is
part of the mobile test suite - are actually not specific to mobile.
This commit merges those tests asserts into the tests already present in
the regular test suite. It ensures that all the existing asserts remains
and the actual coverage stays the same.
*: mail,partner_autocomplete: adapted tests
Added a new function to trigger the adequate type of event on
an element (native JS event to DOM Nodes and jQuery event to jQuery objects),
and refactored the generic event-triggering functions to call this new function.
Let's assume the following situation:
- an empty editable x2many list with date field (or any other
fixed width field) and optional fields
- add a record to the list, but discard it directly
- toggle an optional field
After those steps, the date field doesn't have its hardcoded,
absolute width anymore.
This rev. fixes this issue by clarifying the way the stored widths
are erased when the columns change, preventing to reach a corner
case in which we have stored widths, but we can't apply them, and
thus let the browser uniformly divide the space amongst columns.
When there were records in the list (and the browser computed the
optimal column widths according to them), and the user removes
them, we want to keep the widths as they are instead of forcing
them according to the field's types.
Mainly, when adding the first record to the list, as this is when
we switch from forcing the column's widths (when there is no data),
to letting the browser optimally divide the available space.
Some other cases had to be handled, like the multi edition.
Before this commit, a simple optimization was done: if a field was
modified in such a way that the new value is the same as the initial
value, then it is not considered changed.
However, with the new changes in the ORM, it may be an issue, because
doing so loses the intent of the user. If an onchange changes a field,
then the user changes it back, the server is not aware of that fact.
With this commit, we simply keep the field in the list of changes to
send to the server.
opw #2057230closesodoo/odoo#35890
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When opening a dialog using mouse and closing it, form_dialog_discarded is
triggered, which tries to set focus on form while lastActivatedFieldIndex
is -1, as dialog is opened using mouse directly
do not set focus back to form widget if lastActivatedFieldIndex is -1
task-2031706
closesodoo/odoo#34684
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Aaron Bohy