Url in the web client are supposed to open in a new tab. This was the
way it worked in v10.0 and was lost with the refactoring of the new
views.
We just reintroduce that behaviour with this commit.
Closes github issue #22389
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
With this commit, we change the behaviour of the web client with respect
to spaces in char fields. Most of the time, starting and ending spaces
have no value, and worse, make the data not so reliable.
After this commit, field char will trim by default (so, if the user input a
char as ' abc ', the string 'abc' will be sent to the server instead).
Note that this only applies when the value of the field is changed. If
someone open a form view, then switches to edit mode and save, nothing
will change.
This is the desired behavior most of the time. However, in some rare
cases, this is actually harmful. For example, if we trim the
'decimal_point' field, it will not be possible to enter a whitespace as
decimal separator. In those cases, we introduce a new attribute 'trim',
which allow the developer to desactivate that feature.
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
Commit f45edfbe6d fixed a bug on image fields
but was a partial fix.
The problem is that while adding field dependencies to fieldsInfo,
it did not add them in the fields of the view, making the view crash.
After this commit, views and subviews contain fieldDependency as both info and actual fields of the view
OPW 780021, 781620, 779649
[FIX] web: tests on many2many subviews
closes#20891
With the new views, empty char fields were sent to the server as ''
(empty string) instead of false. This is not the correct behaviour, and
actually cause some problems. For example, if you have a char field
with a unicity constraint, then you cannot set it to '', since there is
only one record that can take that value.
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
A recent fix in web changed the field FieldImage to make sure it also
loads a __last_update field. This is fine, except that a test in
enterprise (web_clearbit_tests) was using a field image, and failed
because it could not find the __last_update field in the demo data.
With this commit, we make sure that the mock server is always aware of
the __last_update field.
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
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.
* crm, project
Add a new feature which allows to put a progressbar in the kanban
columns. The progressbar shows with the same color the amount of
records whose value of a given field are the same in the column.
It also indicate the sum of another given field or simply the total
number of records. It also allows to subgroup the column content.
To define a progressbar, add this as a direct child of the kanban
arch:
<progressbar field="<name of the field to use for subgroups>"
colors="{<one possible value for the above field>: <success, warning or danger>, ...}"
sum="<name of the field to sum or nothing to use total number of records>"/>
Also:
- Properly update record model data's parentID when moving a record
- ...
- datepicker doesn't default to current date by default
- date string in the input is now selected when clicking the field
- adapted the existing tests to the new changes
Before this rev., when the value of a field with widget='domain'
was false, the search_count RPC made to display the number of
records matching the domain crashed, and the widget displayed that
the domain was invalid. This rev. adds a fallback on [] when the
domain is false.
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 rev., all date fields values were off by one day as
soon as the user timezone was negative.
With the new views, all dates manipulated by the JS are moment
instances in UTC, and when being displayed, they are correctly
formatted in the user locale by applying the timezone offset.
However, this should obviously not be done for date fields as
when no time is specified when creating a moment instance, it
defaults to 00:00:00, so applying a negative offset always leads
to the day before.
Remark:
It happens that datetime fields are displayed as a date (e.g.
purchase order line form view). In that case, the offset is
applied on the displayed date.
Christophe Simonis