In some cases, and for historical reasons, the groupby property can be
expressed as a string (for example, 'stage_id') instead of a list of
strings (for example, ['stage_id']).
However, the support was not complete. A crash could happen in some
cases. For example, if there is a group_by: 'stage_id' property in the
context of an action, it works in list view, but adding that view to the
dashboard would result in a crash, without this commit.
Let's assume a form view with field A and B (a one2many list), with
a column with attrs column_invisible depending on A.
If the user sets A manually, everything works fine (the column is
hidden/shown directly). However, if A is updated by an onchange
(e.g. depending on the number of rows in B), it doesn't. This
rev. fixes that issue.
Related to Issue: 1851451
Co-authored-by: Priyanka Kaakdiya <pka@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
closesodoo/odoo#28298
Before this commit, when loading the data and calling the prostprocess,
the viewType was not correctly passed which could lead to broken
behaviour. For example, if one was to load a record from a list view
embedded in a form view, the viewtype passed was the list which
prevented to load the data from the form view.
OPW 1891295
closesodoo/odoo#28279
When creating a record in a grouped kanban view, it tries to add
the record to the first column but if no column exist, it fails
to find the first one and raise an exception.
This PR correct that bevahior by checking it exists a column and
fallback to the view form when it does not.
opw-1902851
closesodoo/odoo#28262
Rev. 42e1efded5 aimed to disable the quick create feature when
grouped by date(time) fields, by only enabling it for char, boolean
and many2one fields. However, the selection case is quite important
and must be handled as well. This is what this rev. does.
Task 1878254
When a kanban view is grouped by a char or a boolean field, and the
quick create option is enabled, the correct default value for the
grouped field (i.e. the value of the column in which the record is
created) should be given (either in the context if that field isn't
in the quick create form view, or as a default value in that form
view otherwise).
Before this rev., it wasn't the case, as it was only working when
grouped by a many2one field.
Task 1878254
when grouped on field types for which it isn't supported.
Rev. 42e1efd disabled the quick create feature when the view is
grouped by date(time) fields. However, it hasn't been correctly
forwardported to 11.0 (with the new views). Indeed, the check was
done only once, at the initilization of the view. So if the user
selected another field to group by afterwards, the quick create
feature wasn't enabled/disabled accordingly.
Moreover, we didn't check if it was available when the user clicked
on CREATE in the control panel. So even if it wasn't (and thus if
there were no '+' icon in the columns), when the user clicked on
CREATE, the quick create widget was inserted in the first column.
This rev. fixes both issues.
Task 1878254
closesodoo/odoo#27867
This fix some inconsistent error on runbot.
In mobile, some views* depend on 'jquery.touchSwipe' library which
is lazy loaded. As a result, the views become asynchronous...
It's why this library is already loaded before running tests in the
mobile test suite. So we can continue to use synchronous views whether
in mobile tests or not.
But some mobile tests weren't in mobile suite...
In desktop, 'jquery.touchSwipe' is lazy loaded and the first test will
load it for others. It's why the first one has to be asynchronous:
https://github.com/odoo/odoo/commit/da7b59045d246c159f93bc75e3f19c6b1221d31c
The inconsistency comes from the fact that all tests are sequential but
we can't garantee the execution order. So, if the test mentionned is not
the first executed one, an error will occur because the view is not
asynchronous.
Now, all mobile tests are moved in mobile suite to be sure that
'jquery.touchSwipe' is loaded.
We also set the default value for size_class because we want a
coherent environment. It is very rare to find mobile devices with
more than 474px wide.
*: form_view, kanban_view, res_config_settings
closesodoo/odoo#28195
On the user's preference, change the timezone to one that is different
from the browser.
Save the form.
Go back to the user's preferences.
Before this commit, every timezone was displayed inside the span that contain
the warning icon, and leaked everywhere on the form view.
This was because of the joint action effects of commits:
86897ca1674dfabb8f7a
Which provoked the field to be re-rendered in edit mode,
but with an $el on which a span was added. `<option/>` elements
were then added to both `<select>` and `<span>`
This did not happen before v12.0
After this commit, there is no display glitch
OPW 1895088
closesodoo/odoo#28108
Currently, the RTL/LTR direction of a report is the language direction
of the current user printing the report.
So for example a customer invoice in french can be RTL and a customer
invoice in arabic can be LTR.
With this changeset we keep a reference to the body language and use it
to choose direction later on.
opw-1890833
closes#27878
Modification in 60aa9ffd0 of web module kanban_view.scss contained
unused CSS style and style that affected usage of AttachmendImage field
in a normal kanban view.
The correct code was added in commit 6e12372 in composer.scss of mail
module.
opw-1892053
closes#27923
Before this commit, when an element with access key has a CSS
position absolute , pressing the key 'ALT' to show the access
key overlay may break the position of the element.
This is due to altering the CSS position of the element which the
overlay is attached to: it becomes `relative`, so that the overlay
takes the whole size of the attached element.
In case of an absolute element, it should not become relative,
otherwise its position on the document may be completely different.
Since the overlay has position `absolute`, if its parent has also
position `absolute`, then keeping both with position `absolute` will
let the overlay take the size of the parent, without changing the
position of the parent.
Task-ID 1885445
The handler function was used directly in the code. The MouseEvent wasn't provided in that case.
This FIX split the handler function and the processing function so that it doesn't interfere.
closesodoo/odoo#27929
When header was too long, the text was breaking into next line.
We want to avoid this behavior in mobile because it causes
a big margin on the top of the list view.
This issue was probably caused by the upgrade of Bootstrap.
task-1878252
closesodoo/odoo#27927
Let's assume a one2many editable list containing a many2one field
(e.g. in a sales order, the product_id m2o in order_line o2m), and
the scenario where the user clicks on 'Create and Edit' in the o2m,
and then presses ESCAPE in the opened dialog.
Before this rev., it crashed because the 'navigation_move' (cancel)
event wasn't stop propagated by the form renderer (the one of the
dialog), and thus bubbled up to the list editable renderer, which
asked its basic model to discard a record it didn't know.
Note: same fix as in 8445baa (done in saas-11.3), but with a
simpler test.
Task 1878254
In Firefox, the input behavior and visual representation (navigation, caret
placement, value selection, etc.) was broken when using a datepicker (easily
reproductible on date and datetime widgets).
This was due to the `focus` event being stopped on the input, which doesn't
seem to be correctly supported by Firefox.
The deleted code was supposed to toggle the picker when the field was clicked
(see odoo/odoo@89093a1) (toggle on click and disable focus) but the lib
correctly supports on focus without extra code.
This also fixes the fact that the datepicker was not open on focus (only on
clicked). In some tests where the field was the first in the form view, it is
now correctly autofocused.
Forward-port: not useful from 12.0 because the code has changed with BS4 and
this has already been applied in odoo/odoo@6692919 and odoo/odoo@c63630d.
Closes#23438closesodoo/odoo#27657
Christophe Simonis