08b2d1f9ac was intended so margin on the top of the body worked (it
seems that wkhtmtopdf only started the body from the first visible
elements).
From a subsequent report, on some document template the CSS could have
adverse effect of not showing the footer.
With this changeset, the CSS is only applied on the body which was the
first intention.
fixes#31531
opw-1925894
closes#31533
With the BS4 update, a traceback occured when clicking on a m2m tag using colors
in a list view.
When using colors on m2m tags, the badge was wrapped inside a `dropdown-toggle`.
However, there is no `dropdown-menu` by default (it is only rendered in FormFieldMany2ManyTags
when clicking on the `.dropdown-toggle`, hence the traceback.
The `dropdown-toggle` class is now only set if necessary.
Task 1925313
closesodoo/odoo#31445
The margin-top/margin-bottom on a address on the top of the report does
not work because:
- display flex on an address in wkhtmltopdf is not perfectly implemented
and seems to remove vertical margin
- margin-top on the page first visible element is removed
To fix this issue, this code remove the display:flex on the address
widget and add an empty "visible" element at the start of pages.
opw-1925894
closes#31184
Have an editable list that begins with a date/time field
create a line.
The first field is focused and the datetimepicker is popped up
Now, stroke ESC key
Before this commit, there was a traceback because the datetimepicker received an erroneous
BLUR/INPUT event
After this commit, there is no traceback as we detroy the widgets of the line
(including the datetimepicker) before removing the row from the DOM
OPW 1932409
closesodoo/odoo#31342
This rev. fixes 3 issues with async (field) widgets in the kanban
view.
From rev. 5faec34a, widget'$el doesn't exist before start. This
means that for async widgets, one can't interact with the widget's
$el right after calling appentTo. In KanbanRecord, this is exactly
what we did for both field widgets (<field name=.../>) and widgets
(<widget name=.../>).
Moreover, when the kanban view was updated (e.g. when the user
refined the search using the search view), and the rendering was
async (because of the presence of an async widget), the renderer
didn't wait at all for the widget to be ready before updating the
view. This caused flickering, mostly, but also a crash in
accounting with the JournalDashboardGraph widget (because
on_attach_callabck was called before the widget was ready). To
reproduce this particular issue, go to accounting, add a filter
that doesn't match any record and save it as favorite (default),
press F5 (no record is displayed), remove the filter.
opw-1925079
opw-1925479
Fixes#30087Closes#31254closesodoo/odoo#31327
* web, web_editor
The logic which chose if the user text color was supposed to be used as
bootstrap "dark" text color or bootstrap "light" text color
(https://github.com/odoo/odoo/commit/8b2dbd1441d6713d9072db03e8d3cb6c2246410f)
was fine when using the default theme with default bootstrap but was not
working as intended in some themes.
This commit also introduces a more accurate and complex method to
determine the correct contrasted color in most cases.
closesodoo/odoo#28468
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
Add an 'enableRelationalFetch' option in _readGroup who force to make
only one rpc for x2m and reference fields.
Usefull to avoid useless (and blocking when too numerous) rpcs (tags
field in a kanban view for example).
Task #1878113 (2/2)
closesodoo/odoo#27731
The utility function xml_to_json, which is mainly used by the views to
parse their arch (from string to xml tree) had a peculiar behaviour: it
tried to process some attributes as json. If by chance, these
attributes are valid json, then they are replaced by their parsed value.
It is difficult to say why it could be useful. Maybe this was done to
prevent using pyeval many times later on. But if that is the case, it
should be done by the view code and not the utility function (the view
can precompute all attributes once).
Also, this behaviour is annoying for code later in the chain, which
needs to check if what it gets is an object or a string. With this
change, attributes are always returned as string (at this point).
closesodoo/odoo#28133
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
Nicolas Lempereur