Field widgets now have a key 'context' that let them
extend the context of the dataPoint (e.g. list).
In particular, widgets on binary fields enforce the contextual
item {bin_size: True}, so that the server gives the size of the
binary field as its value, instead of its content.
This change on binary fields reduces network load when accessing
a view with binary fields.
Revert partially 255e8ca3d9
Removed widget 'download_link', as it was a sub-version of widget 'binary':
it did the exact same thing (representation of binary fields by means of a download link)
in a much better-looking way (download icon + filename as text of the download link,
instead of just a download link with text "Download").
Also, the values of binary fields might be already a human-readable binsize (e.g. 2.52 MBs),
instead of its plain textual string representation in base64:
The contextual parameter 'bin_size', when set to true, does not download the data of binary fields.
As a consequence, the server provides the sizes of the binary, instead of their value.
Binary fields were simply shown simply by their textual representation in list views,
e.g. the base64 string.
There was no formatter for binary fields, therefore it has been implemented so that
it displays its estimated size.
Binary fields in list views had a download link in v10.0.
We provide this feature back by means of a widget called 'download_link'.
It is also possible to define an option to set the field name having the filename as its value.
Example:
<tree>
<field name="fname"/>
<field name="datas" widget="download_link" options="{'filename': 'fname'}"/>
</tree>
with the following record: {fname: 'document.txt', datas: 'Cg=='},
we get a file named "document.txt" by clicking on the download link.
Closes#21996
In v10, a `Float` field with `widget="monetary"` option uses the decimal
precision of the field. In v11, however, it uses the decimal precision
of the currency. However, in many cases `widget="monetary"` is used in
the sole purpose of displaying the currency symbol. The precision of the
field sould be kept.
This commit introduces the support of the decimal precision of the field
for this specific use case thanks to the `field_digits` option:
```
<field name="pouet" widget="monetary" options="{'field_digits': True}" />
```
If such an option is used, the field precision will prevail over the
currency precision.
Related to #21686
opw-800279
- Set the currency rounding to 0.001 (3 digits)
- Create an account move
- Add an account move line, set an account
When switching from edit/read-only mode, the rounding switches from 2 to
3 digits.
This is because, in edit mode, the format method is the method of the
float widget. Therefore, in this case, the formatting doesn't take into
account the currency rounding.
To avoid this, we simply use a `noSymbol` flag to avoid adding the
currency symbol, while keeping the monetary rounding.
opw-800279
Let's have:
- on res.company a binary file field named x_file
- on res.users a related binary field to company_id.x_file, and make it readonly
- On the res.users form view, display the new field
Before this commit in create mode, upon clicking on download the file, the server crashed, because the record id was empty.
Then, the JS crashed in turn because of the unhandled 404 from the server.
Since the id of a new record will always be unset, we choose to disable the download option in this very specific case
OPW 777042
Before this fix:
A readonly monetary field was not updating
its currency symbol when selecting another currency.
Scenario:
1. Activate multi-currency with $ (default) and €
2. In hr_expense, go to My Expenses to Submit
3. Create a new expense
4. Select 'EUR' as currency
=> Unit Price is correctly updated with €, but not Total.
With this fix:
Total displays the correct currency in edit mode.
Explanation:
Monetary fields in readonly are relying on _formatValue() to
display their value.
_formatValue() uses this.formatOptions.currency, which stores
the currency at loading of the field. We must update its value
whenever there is a change of currency.
opw-783378
The JournalDashboardGraph requires nv, which is lazyloaded. Before
this rev., a crash occurred when this widget was instantiated and
destroyed before the loading of the lib was complete (because a
function of the lib was called in destroy()).
For instance, press F5 (to ensure that nv isn't already loaded),
activate some throttling in the network tab, go to Accounting and
as soon as the dashboard shows up, click on another menu.
opw 781628
As a way to optimize loading, images are not necessarily fetched in db.
They have, in their url a "unique" parameter, which is the last_update date on **the record** and controls on the python-side whether it should get the image from a cache or from the db.
Before this commit, this __last_update field wasn't present in the view, so it wasn't fetched, and writes on a model's image worked but did not refresh.
The image displayed was the old one.
After this commit, when the image field widget is present, we force the loading of the __last_update field of the record.
Upon update, the image displayed is the new one.
OPW 777552
closes#20457
With this commit, we allow an onchange coming from a field to modify the
same field. This was not working for field widgets derived from an
input field.
This use case was not correctly managed as the function evaluating if the
value has changed compares datetime and date.
This triggered an issue if the widget `date` was set on the field `date_order`
on a purchase order for example ; it was not possible to create a record as
the datapoint was set `dirty`.
This rev. ensures that a `field_changed` is not triggered if the day is the same
on a date widget.
This rev. also adds support of `datetime` fields on date widget, which appears
to be a valid use case.
Fixes https://github.com/odoo/odoo/issues/20311
Before this commit, the image was directly built without using the corresponding
template, which set some properties on the image (class, width, etc.).
This commit ensures that tab navigation works properly when editing a
form view that contains input fields with phone widgets. Previously,
pressing TAB would skip those fields.
This commit ensures that tab navigation works properly when editing a
form view that contains input fields with phone widgets. Previously,
pressing TAB would skip those fields.
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.
Before this commit, a field handled with a widget url was given its value (href) as its text, fully displaying the url.
Moreover, the display was odd and did not match that of buttons
After this commit, if the field contains a text attribute, we use is as the text of the link.
The link also correctly displays and looks like a button (in a form view)
Of course, a test for this new field widget feature is implemented
closes#19587
Go to General Settings, click on 'Change Document Template', and
in the opened dialog, click on a template.
Before this rev., it automatically closed the dialog, which was
not really convenient.
This rev. introduces a new field widget (image_selection) for
this use case, and ensures that the dialog doesn't close when
a template is selected.
Test written by @mba-odoo
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.
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.
Purpose
=======
Projects and soon sales teams have a manual "favorite" button that calls a toggle_favorite method
It should actually be a widget on a boolean field
Specifications
==============
Develop a favorite widget for kanban view that allows to toggle a boolean field
Probably update boolean field to allow inverse method on it
Functionally nothing changed.
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.
Purpose
=======
Currently, it's not possible to activate a boolean on a non-editable list view without adding 2 buttons linked to a python method. These buttons aren't aligned and the result is not pretty.
This commit adds a new widget that allows to toggle a boolean record by record by clicking on the slider.
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: de403dc1ab).
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).
Alexandre Kühn