| Age | Commit message (Collapse) | Author |
|---|
|
The o_row class mechanism is supposed to be used to put another
element next to a field, like a button for example. However,
in the case of phone and email field, the o_text_overflow hack
gets in the way.
The problem that o_text_overflow is trying to solve is when you
have a long email, the table used to display the form view fields
tends to use very long cells (td) so it can display the whole email
address. This behavior completely breaks the form view, even though
the email address is clearly set to wrap in css. The o_text_overflow
class is a hack that forces the table to think that the email is
small, then defaulting to the width 50% css rules. If the email is
too long, it is correctly wrapped inside the cell, without breaking
the form view layout.
However, when we need to add a button next to those fields, this
hack gets in the way of the o_row class css rules, completely
wrecking it. We looked for a fix with qsm-odoo for hours but were
unable to find one that did not require a complete rewrite of the
form view css rules. In the end, we decided to remove the hack from
the phone field and keep it on the email field, as we think it is
less common to have a very long phone number than to have a very
long email.
|
|
The FieldDomain allows to open a list in a dialog to display the
records matching the current domain. In this dialog, clicking on
a record should do nothing (this was the behavior before the new
views).
Before this rev., it actually tried to open the record and it
produced a crash.
|
|
Before this commit, a list containing a handle widget would only display
the handles associated with non-zero integer values. This is due to the
fact that unset fields are hidden in Odoo, while a field is by default
considered 'defined' if its value is truthy.
We override the isSet method for the handle widget to always return
true. This tells the handle widget that the associated integer value is
always defined, thereby ensuring that the handle will always be shown.
|
|
Since the new views, the 'o_input' class has to be set explicitely on
<input/>, <select/> and <textarea/> elements to have the proper styling.
|
|
In Odoo 10.0, `Char` fields with a maximum `size=` attribute were
indeed limited in the web client.
|
|
With the new views, we stopped using the browser timezone to
display the dates in Odoo, and we used the timezone defined on
the User profile instead. When loading the webclient, the
timezone offset was put into the session and used to display all
dates. This wasn't a good idea.
The given offset was computed for the current time, meaning that
it may be incorrect for specific dates (e.g. with the daylight
saving, the UTC offset of today is not the same as 6 months ago).
Moreover (but less likely), as the offset was stored in the
session, it wasn't recalculated afterwards. So if the offset
actually changed during the session (e.g. from or to daylight
saving time), the displayed dates were incorrect until the user
reloaded the page.
With this rev., we don't retrieve the offset from the server
anymore and we use the browser timezone again (like before the new
views). However, we keep the computation of the offset (on the fly)
in the session, so that it can be mocked in the test environment.
|
|
Before this commit, it was not possible to copy the contents of a
multiline text field in read-only mode in Firefox without losing all
line breaks in the process. This is due to a bug affecting div tags
(see https://bugzilla.mozilla.org/show_bug.cgi?id=1390115) in Firefox.
This commit ensures that the text in a text field is surrounded by a
span (as opposed to div) tag.
Note that spans were used in saas-15, so we are in fact simply undoing
the change to divs introduced by the new views.
|
|
Let's assume that we have a form view with a one2many field
displayed as a list containing two fields A and B (an input field,
e.g. a char field). An onchange on the one2many is triggered as
soon as A changes. This triggers a reset of the one2many which
thus redraws the corresponding line by resetting its widgets.
A problem occured when the user updated A, and directly (before
the onchange returned) updated the input field B, as in this case
the new value in B was erased when the onchanged returned, as the
widget was reset with its former value (or with the value returned
by the onchange, if any). Note that the model was aware of the
change on B, so the model and the UI were actually desynchronized.
This was quite hard to reproduce in practice, by hand, but it
occured in the tour testing 'the flow', in the form view of
account.bank_statement, with fields partner_id and amount of the
line_ids one2many.
With this rev., we don't re-render the input fields if there are
pending changes that haven't been acknowledged by the model.
|
|
With the new views, we introduced a system where some fields could
notify immediately the rest of the system that they have been changed.
It is really cool, it allows real time edition (with onchanges).
However, this was a little too much. In some cases (an onchange that
returns a warning), it was counterproductive. So, we decided to simply
remove the feature. This commit only make sure that it does not happen,
and we will do a deeper pass later to make sure that no useless code is
left behind.
Note that this means that we can reintroduce the functionality really
easily later, eventually protected by an attribute.
|
|
In the editable list, when pressing enter, the cursor goes to the next line and
the current row is saved.
This should not be the case for a textarea (i.e. in the FieldText widget). In
this particular case, we just want to continue editing the textarea.
|
|
The translate feature of widgets html and html_frame had been
broken by the new views refactoring. This commit restores it for
the html widget, and removes it completely for html_frame as it
wasn't working correctly before the new views anyway (moreover,
it had already been disabled for mass_mailing: de403dc1ab440b9b08ea7fce189cd157745dfe74).
This commit also ensures that the changes are correctly saved for
the html_frame widget. Note that this widget still needs to be
converted to our new coding guidelines.
|
|
The MonetaryField can be rendered with or without a currency. The
currency can change during the lifecyle of the widget (e.g.
currency field in the view, whose value is set by an onchange).
More precisely, the widget can be instantiated without currency,
then a change on another field can trigger an onchange which sets
the currency, and our monetary widget is re-rendered with a
currency.
Before this rev., this wasn't supported in edit mode because the
$el's root node was different if there were a currency or not
(it was an input if there were no currency, and a div containing
an input and a span otherwise). This root node being rendered only
once (at the creation of the widget), the widget wasn't re-rendered
correctly if the currency was suddenly set or unset.
This fix makes the widget behave uniformly whether or not there is
a currency, so now it is always a div containing an input (and
optionally a span if there is a currency).
|
|
The update_field event is not used anymore so it needs to trigger
a field_changed instead.
|
|
Rev. https://github.com/odoo/odoo/commit/c5f8f35747b4ca9633c664d6be74614c5ce22fcd
introduced a regression: the input of widgets 'email' and 'url' was not correctly
focused anymore with tab navigation.
The method `getFocusableElement` on their common parent (`InputField`) has not been
correctly overriden because `_super``was not called in edit mode.
|
|
The tab navigation was only working in edit mode. Entering a readonly form
view with input fields was causing a traceback.
As the default browser behaviour has been overriden with custom navigation,
we need to specify which widget can be focused (e.g.: url, many2one, etc.).
|
|
Field widgets must format and parse values according to the widget
type, not to the field type. For example, if a monetary field is
inserted in a form view with widget="float", the field's value must
be formatted with the float formatter, not the montetary one. This
wasn't the case before this rev.
|
|
Commit 9966e4b added calls to preventDefault() on the keydown event
for left, right, up and down arrows, to prevent the page from
scrolling. However, it also prevents the cursor from moving inside
the inputs. Since the initial issue only concerned checkboxes, this
rev. moves the preventDefault() calls from AbstractField to
FieldBoolean.
|
|
from project task kanban view (PR #17165)
|
|
With the new views, the attribute autocomplete on input was no
longer supported. We simply reintroduce its support in this commit.
The basic attribute values are 'on' and 'off' but one may want to use a
random string.
Note that an input with type='password' is a special case: the autocomplete
attribute should always be set to 'new-password' to remove autocompletion
(autocomplete='off' doesn't actually remove the autocompletion).
|
|
With the new views, the special attribute password was no longer
supported. We simply reintroduce in this commit proper support to
display password fields with *.
Note: we may want to display passwords with a static number of *, but
this requires some thoughts on the usability of the change. We simply
reintroduce the previous behaviour here.
|
|
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.
|
|
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)
|
|
|
|
|
|
In the form view, when the user saves a record (with a multilang instance),
an alert is displayed to display all modified translatable fields.
|
|
Previously, when a checkbox was re-rendered, it was losing focus
since it was removed and re-created. Now, if the checkbox itself
is the origin point of the re-rendering, we give the focus to the
newly re-rendered checkbox, resulting in a seamless experience
just as if the checkbox was never removed and re-rendered.
|
|
Previously, the checkbox was not checked when it was clicked in
editable list view, it only opened the row but did not check the
checkbox.
|
|
Before this commit, it was not possible to see the difference between an
unset float field (with a 'false' value) and a set field (for ex, with
value 0)
This was due to the fact that the formatFloat/formatMonetary functions
format false values as the number 0, unlike many other formatting
functions.
|
|
Before this commit, only fields which were specializations of the
`InputField` were handling up/right/down/left navigation in editable
list view. As m2o field is not an `InputField` (yet?), it was not
possible to navigate from one of those for example.
Now, navigation events are handled by the `AbstractField` class. If a
given field has to handle navigation a different way, it is its
responsability to stop the associated navigation event. For example,
`InputField` instances are stopping the left/right event if the cursor
is not at the start/end of the <input/> element.
Also, before this commit, there were many events ("move_down",
"move_left", "move_next", ...). Now there is only one event for
navigation: "navigation_move". This event is given a "direction" data
("left", "next", ...). It also comes with a "target" data which is a
reference to the last `AbstractField` instance the navigation event
has crossed.
|
|
... in x2many editable list views.
Field widgets can detect that they are at the origin of a
field_changed event, so that they don't re-render themselves when
they are being edited.
This didn't work for fields inside x2many list views. This wasn't
a big problem for most of the fields, because the cursor position
was automatically reset after a re-rendering, but it wasn't
working for monetary fields that empty their $el before each
re-rendering.
This rev. fixes the issue by making the field widgets inside
x2many list able to detect that they are the origin of a change,
and thus removes the now useless code that restore the cursor
position.
|
|
`DebouncedField` and `InputField` classes were not properly factorized,
some of the DebouncedField code had to be part of the `InputField`
class (which is a specialization of `DebouncedField`). Indeed the
`FieldText` class, specialization of `DebouncedField` class, was missing
properties which were part of `InputField` and was duplicating code
which was already defined in `InputField`.
For example, it was not possible to navigate out of text fields in
editable list views with the right/left keys as this was part of the
`InputField` class.
Note: the FieldTextHtmlSimple class was implementing the `commitChanges`
function differently than `DebouncedField` but this was in fact not
necessary. This is why documentation update has also been done for this
by this commit.
|
|
Before this rev., if you opened a form view with, e.g. a float
field, that is unset, and then click on edit, then save, it
actually saved the new value for the float field (being 0),
whereas it shouldn't do any RPC as nothing changed.
This is because the former code couldn't detect if the value "0"
in the input is there because the field is still unset or if the
user simply set it to 0.
|
|
The button allowing the user to translate fields (existing in
previous versions) was not present.
|
|
Since the new views merge, a lot of design elements were broken. This
was particularly impacting the fields in the editable list view; indeed
the editable list view is not using an inline form view anymore so the
fields in the list were not properly styled as the LESS was still
defined assuming the form view environment (for example the invalid
fields were red for o2m fields in form view but not in editable list
view even though they got the right CSS class).
This commit refactor the LESS following these rules:
- No more division of non-layout and layout rules. Dividing LESS rules
in x_layout.less and x.less was a mistake. Many rules can be
considered to be layout and not layout at the same time, developers
always have to switch from one file part to the other, many CSS
selectors (and rules!) are duplicated for nothing, ...
- Field style is extracted from x_view.less and put in the new
fields.less file. As before, the fields_extra.less will contain the
rules specific to community so that the enterprise repo can override
those by replacing the whole file.
- Many classes have been renamed so that o_form_x_y becomes o_x_y as
many classes can now be applied outside of form view. These classes
should not be used in templates anyway.
The commit also changes the DOM of fields so that it is more minimalist
(no useless parent div, etc).
Input elements are not automatically styled anymore, they have to get
the o_input class explicitely. This allows to fix lots of small style
bugs of previous versions (required monetary field had not the proper
style, readonly m2m tags appeared as editable, ...). This also improves
the LESS code.
The editable list view should also completely stop flickering on chrome
and firefox.
The commit also removes the orange outline on list view dirty cells.
The commit also removes deprecated static xml, LESS and other code.
Notice there are still styles to restore/fix and LESS to improve.
|
|
With this commit, we try to improve the way navigation is done in the
list view. In particular, we want to make sure that pressing TAB on the
last editable cell move the cursor to the next line (and create a new
line if necessary).
Also, we add a few tests for keyboard navigation (it was almost not
tested before this commit, and while working on this commit, it was
broken at some point).
|
|
|
|
When we unselect a line in a one2many list, we ask for all fields to
commit their changes (because many fields are debounced, so we may not
know their current last value). This is good, except that it could
trigger an extra field change event, which may in turn trigger a second
onchange.
We solve this issue by improving the _setValue method and delegating the
comparison to a new _isSameValue method.
It is particularly relevant for field types such as integer, which are not
stored as a string.
|
|
`session` is not an field widget attribute anymore.
One should use `getSession` instead.
This commit also introduces tests for the `binary` field.
|
|
hr_holiday was the only module that used a widget=toggle_boolean on a
button in a list view. That behaviour was implemented as a column
widget in the previous list view, and was not reimplemented in the new
views. The feature is useful, but this was not done properly: it is
better to use a widget on a field (that was the intent) instead of doing
a weird hack like it was done.
With this commit, we update hr_holidays to use the ToggleBoolean widget,
which is supposed to work on every views.
Also, we fix the toggleboolean widget (it was not properly rendering
tooltips, and changes were not saved in readonly list view).
Note that it as the side effect of being better from the point of rpcs:
before, the list view had to reload itself. Also, another advantage is
that models do not need to implement custom methods (such as
toggle_payslip_status) just to toggle a boolean...
|
|
|
|
Before this change, the redering throw an exception when we try to open
a form view with a virtual id.
eg: recurrent event in calendar
|
|
The '_render' function of field widgets can be called several
times in the widget's life cycle (each time its value changes).
The JournalDashboardGraph appends a new 'svg' to its the $el at
each rendering, so it must empty its $el at the beginning of each
rendering.
Before this fix, several graphs were displayed in the same kanban
card in the Sales dashboard when, e.g., the user changed the color
of the card.
|
|
... to clean up once the test is finished, because it doesn't
work.
The previous solution to clean up only deleted ace and require
from window, but doing this didn't force a reload of the libs for
a potential second test using ace (because the scripts were still
in the page). Trying to remove the scripts from the page doesn't
work either because the loadJS function uses an internal cache
to prevent from loading twice the same lib.
So if we want to have more than one test on ace, we can't clean up
the libs.
|
|
before this commit when toggling allday flag in calendar form view, it was
possible to have one day error.
The input datetime is wrong when the user don't use the datepicker widget
(insert date by keypress instead of click on datepicker)
sometimes, the value could be null (crash because try to clone false)
|
|
* account, mail, sale
Since the views refactoring, modifiers were not properly handled
anymore (readonly/required not recomputed, use of readonly/required
of "python field" instead of "view field", ...). This commit tries to
implement a system which allows to handle the modifiers (re)computation
the same way for all the basic views.
For this to work, many specialized renderers behaviors have been moved
to the basic renderer so that more mechanisms are shared (especially by
the form renderer and the list editable renderer). The list editable
renderer is hugely impacted by this commit.
Here is a list of key changes:
- The basic renderer now has a `_renderFieldWidget` function which is
used without modification by the form and the list renderers.
- Modifiers have to be registered thanks to the basic renderer
`_registerModifiersData` function (this is done automatically for
fields by the `_renderFieldWidget` function for example).
- All instantiated widgets are accessible, organized by record, and
ordered in a special basic renderer variable.
- The code which resets the widgets of the form view and the code
which updates the row of a list editable view is now shared in the
basic renderer and now also automatically updates the DOM according
to the reevaluated modifiers.
- The last point has an huge impact on list editable renderer: all the
widgets have to be instantiated when editing a row (even readonly and
invisible ones) as they can be switched to editable/visible during
edition (after a modifiers update).
- `replace_element` and `readonly` options of `AbstractField` are
useless: widgets are now always replacing the list editable cells
in edition and the `readonly` widget mechanism is replaced by the
notion of 'focusable' widgets.
(see `AbstractField.getFocusableElement`)
- The 'tab' navigation mechanism is impacted by the previous point,
some code sharing have been done in basic renderer for this too.
- `AbstractField` does not care anymore of the 'required' status, this
is the view responsability to check that a required field has a set
value on save.
- Some list editable bug fixing (e.g. it was possible to edit multiple
rows at the same time, it was not possible to navigate towards the
previous field, crash on o2m add an item click, ...)
- The mockserver now properly simulates server modifiers computation.
- ...
Note: list editable style may be worse than before this commit but a
CSS update is coming in a few days.
|
|
When you try to empty a date or datetime field, you get a traceback
saying that 'clone' and 'isSame' are not functions.
This error occurs when you empty the field because the value is 'false'
and you cannot call 'clone' or 'isSame' on false.
To fix this, we ensure that value is not false before calling these
methods on it.
This bug has been introduced in rev: https://github.com/odoo/odoo/commit/c32724eae06c987e74a0600f1669696e499edc33
|
|
The client must receive the tzOffset to apply this on all hours.
To use the date picker we must change the date to apply the change
in the user's tzOffset, without this change the result is wrong.
For datetime widget we must change like it to avoid max stack error.
The server send the tzOffset, if it's undefined, by default the client
use the browser time offset.
Every test are change to use tzOffset.
A test is added in calendar to use the click by position for the
fullcalendar lib. This test create and drag and drop an event to check
timezone error and error when we use default value in the context.
Use formating date like 2026-04-04T08:00:00Z instead of 2026-04-04 08:00:00
is important for phantomjs, because it's crash without information if the
formating is not the standard format.
For the parsing, when the client receive a server date the date is utc
formating but when it's parsed from the client is in the user's timezone
|
|
The field widget html wasn't implemented yet in the new views. A
very basic implementation was done in addon web. It only handled
the readonly mode so that the field were displayed in studio.
This commit removes this basic implementation from web, and re-
introduced the old one, converted, in addon web_editor.
|
|
Debounced fields do not notify their environment each time their
value changes, but rather wait for a given delay after the last
change. Input fields allowing the user to type text should be
debounced. The AceEditor is one of them.
Note: this should be tested, but i can't find a way to simulate
text entries in the ace editor.
|
