When a SelectCreateDialog was opened with a given domain, this
domain was completely lost if the user wrote a new domain (or
groupby) in the searchview, whereas they should be concatenated.
Suppose that there is a one2many list in a form view containing
a field F, displayed with no widget, and that F is also displayed
in the one2many form view (opened when clicking on a record of the
list), but that in this form view, F is displayed with a widget
requiring specialData (additional data to fetch alongside the
record), e.g. widget="domain".
Before this rev., it crashed when this happened because those
specialData weren't loaded when opening the related record.
Credit goes to @pga-odoo for reporting the bug and reproducing it
in a test.
DebounceFields debounce the function that notify field changes to
their environment (using _.debounce). It may happen that this
function is called once the field widget is destroyed (e.g.
type something in a char field and quickly click on Save, the
function is called directly by _commitChanges, but the debounced
call is still pending). It may be a problem if the subsequent
code does something like this.getSession().some_key, as if the
widget is destroyed, it has no parent that can provide it the
session, and thus it crashes.
Also rename attribute _debouncedStarted into _isDirty as it makes
much more sense.
Summernote doesn't call the onChange callback when changes are
done in the code mode, so the html field isn't aware of those
changes. It means that if the user does some changes in code mode
and then save directly (without coming back to normal mode), those
changes are lost.
This rev. ensures to save every changes by manually come back to
the normal mode before saving, as this will correctly trigger the
changes. Actually, it simply restores some code of the previous
implementation (before new views) of this widget.
Passing multiple ids wasn't correctly handled as the argument `record_id`
was wrapped in a list of list, which is not hashable.
The wrapping is now handled by the caller.
Before this commit, the renderer interpreted the special tag, but ignored
modifiers and attributes.
Most nodes are rendered by the `_renderGenericElement` method, so this behaviour
is automatic. However, special tags need to do it explicitely.
Before this commit, when creating a new record, we only looked at the
main fields to determine if a call to onchange was needed. This was not
enough, since sub fields (fields in a one2many for example) can have an
onchange.
This was an issue only for new records with onchanges in sub fields, but
no onchange on main fields. For example, the merge contact wizard.
To solve this issue, we had to propagate the current view type from the
field to the basic model, because otherwise, the main viewtype was used
to compute the onchangeSpec, and that is not always correct.
When grouping on a selection field, the read_group may return a
group for value false (containing records with the selection field
unset, typically). When this happened, there was a crash because
the BasicModel didn't handle that case (it assumed that the value
of the groups was always a valid key of the selection).
The model MassMailing overrides read_group to handle the case when
it is grouped by field state, which is of type selection. However,
it sets as value for each group the array [key, name] of the
selection option, which is incorrect (it should set key as value,
like the default read_group does, and as the name is known client
side anyway).
This case was handled by the old views, but it isn't by the new
ones, which are less permissive. We choose to fix the read_group
override instead of allowing both cases in JS, as it is always
better to have a clear and single API.
Before this rev., the FieldRadio didn't work on selection fields
with keys like "0", "1"... i.e. strings that can be converted to
numerical values. This was due to an automatic conversion of those
keys to their numerical value by JQuery, so when the user changed
the value, an unknow key was sent to the server (e.g. 1 instead of
"1"), causing a crash.
This rev. changes the logic a bit so that the keys are no more
written in the DOM, but their index in the selection are.
... for 'compute_at_date' field (default 0, 'Current Inventory').
Before the new views, this value was selected by default by the
FieldRadio, but it was a mere coincidence. Indeed, as the field
had no default value, no value was specified in the default_get,
and for no reason, the widget selected 0 as value.
Anyway, as this behavior was wanted, we simply specify a default
value in the action.
The server doesn't make a distinction between an unset selection
field, and a value 0 (integer). So when 0 is a valid key for the
field, the server returns false as value if the field is unset, or
if its value is 0, which is not really convenient.
As a consequence, when the value is 0, it appears as unset in the
interface. To circumvent this, we automatically converts false
value of selection fields to 0, if 0 is a key of the selection.
Many2many default value can be a list of ids, and in that case, we did
not properly load data.
It could be seen by selecting a few contacts (in list view), then
opening the 'Merge contact' wizard in the sidebar (action menu). Before
this commit, the wizard did show a list with some empty rows (for the
field partner_ids).
In the xml definition of views, a 'currency_field' can be specified
in the node options:
<field name="amount" widget='monetary'
options="{'currency_field': 'currency_id'}"/>
It indicates which field the monetary widget has to use to
determine the currency to display.
Before this rev., the widget didn't look for the 'currency_field'
in the options, but directly in the node attrs, so this simply
didn't work. This was for example the case on the crm.lead kanban
and form views.
This rev. removes some html injections issues:
- in char and text field widgets
- in phone field widget in mobile
- in list views (when no widget is instantiated)
... from a new record.
Steps to reproduce the issue:
- go to a multi-record view (e.g. list) of basically any model
- click on 'Create' -> it opens a form view in edit mode
- click on 'Discard' -> it goes back to the list
- click on an existing record -> it should open the selected
record in readonly.
However, it didn't display the data of the selected record, but
the default data of a new record (the result of a default_get).
This was because the changes weren't properly discarded when
reloading from a new record (it rather restored the record to its
initial state, i.e. to the result of the default_get).
Before this commit, when a test in the qunit test suite failed, the
error displayed by the runbot was not really interesting. It just said
that test_01_js failed. With this commit, each assertion error is now
logged as an error, which means that they are displayed in the short
error log by the runbot.
With this commit, we introduce a benchmarking infrastructure: a new
controller, accessible at the route /web/benchmarks which will render a
new template (web.benchmark_suite).
This template uses benchmark.js and qunit.js to display a list of
benchmarking informations. For example, the number of op/s for
instantiating and destroying a list view.
I hope that this is the start of the beginning of taking the habit to
check our JS code performance sometimes, and making sure we do not have
large regression without a good reason.
The form renderer defines inline style on the groups it renders to
set the width of their children according to the col and colspan
attributes specified in the view.
However, before this rev., this impacted inner list views (for
x2many fields), as their columns get an harcoded width as well,
whereas they shouldn't.
This was for example the case in the stock.location.route form
view, for the push rules and procurement rules o2m fields.
Before this commit, the tour tips were overlapping the chat windows.
This was due to the fact they always had a z-index of 1051 wherever
they were. If a tip was placed in a location where none of its
ancestors created a new stacking context, the closed tip was then
positioned above everything else, including the chat windows.
A simple solution would have been the one proposed by this commit:
https://github.com/odoo/odoo/commit/856e78b35a47a8732e5bd4da1cce247df70e5414
However, as it explained, this would not be entirely correct. In the
website, elements are using z-indexes and would thus hide closed
tooltips when it is not wanted if those have no z-index at all.
The solution this commit is making is to force the creation of a
stacking context for tooltips' parent. The z-index will still exist
on all tips (closed and not closed) to force them above every other
elements, but now only elements of the same parent. This is indeed
more correct (but maybe still not entirely): website tooltip are
often placed in the body (as it is the element which scrolls) and
are thus still placed above elements like the navbar as their
z-index is left high. However, when placed in the appswitcher, they
will now be placed above appswitcher elements only (and thus not
above outside elements which are themself above the appswitcher
(e.g. the chat windows)).
opw-743330
Caused by a stupid programming error.
Also refactor a bit the code that performs mention RPCs (that are
throttled) to allow to override the throttling value for the tests.
Editable grouped list views isn't a supported feature. Before this
rev., grouped lists weren't automatically set as non editable, so
it could cause crashes when the user clicked on rows of grouped
lists with editable="top" or "bottom".
This was for example the case in Timesheets > All timesheets ->
go to list view.
The 'data' attribute of exported datapoints (using 'get') must
contain a value for each field in the view, and the default value
is false when those fields are unset. The code manipulating those
datapoints supposes that this is the case and it makes it easier
and clean.
However, it wasn't the case for x2manys in new records for which
the default value contains CREATE commands with missing fields:
in that case, those missing fields weren't added in data.
This caused a crash in the Employee form view, in edit, if the user
clicked on 'Create and Edit' of the 'Working hours' field, because
some code in field_utils assumes that if the value of a date field
isn't false, it means that it is a moment instance (but in that
particular case it was undefined).
in res.company write(), create a sub method _validate_fiscalyear_lock()
so that it is easier to inherit to modify or extend its
functionality.
Was PR #16615
Introduced by 8f39ad2be6 which was
intended for 9.0. It does not work well in 10.0 because here users
have the possibility to specify their own tracking numbers directly in
the POS interface. This causes issues when eg. the user specifies the
same lot number as is already reserved by the system.
opw-742657
Creating a mail template which is complex and compatible with all mail
clients is a very difficult task as each mail client supports a
different subset of basic CSS rules.
This commit fixes 3 problems which were occuring in outlook and/or
thunderbird but not in gmail:
- Main layout horizontal overflow
-> change 24px horizontal padding of main layout to 3% and set the
width to 94% (so that the sum is 100%)
- Fixed 600px content was full width instead
-> Change the .o_mail_wrapper to be a <table> element instead of a
<div> element. The table is full-width and contains one row of 3
cells: an empty left one, a fixed 600px-width center one and an
empty right one. This allows to have the same layout as before but
without using the unsupported max-width css rule.
- Texts were not using the right color and font-size
-> <p> elements were not properly inheriting the color and font-size
properties, so force the style on <p> elements.
opw-743156
This was causing an error in the form rendering as a group does not
accept text as direct child (and displaying '/>' as text was probably
not the desired behaviour.
The buttons were not updated after column creation.
This was causing an issue in an empty kanban when you created a new column,
the 'Create' button was not highlighted.
After the record deletion, the parent should be updated to take the deletion
into account.
This was causing an issue in the Kanban view: after a column deletion, it appeared
again if you created a new one.
The attribute `widgets` has been renamed in rev https://github.com/odoo/odoo/commit/7ff8aa73e17b281b3e2bc4c7275d020eab0204e7#commitcomment-22116249
However, KanbanRenderer still uses a `widgets` attribute, not for the fields
widgets but for its columns (or records if ungrouped).
These widgets weren't correctly destroyed since then.
This was causing an issue when you were trying to quick create a record after a
column creation (that generates an update): the quick create was added in the
first old column (which was not in the DOM anymore) so you couldn't see it.
The kanban group expects to have local ids in its data and not the whole
datapoint.
This was causing a traceback when adding a new column after adding a record.
Aaron Bohy