Before this commit M2Mtags widget did not translate.
This was because no context was given to the rpc that fetched the fields
Hence, the lang was not passed.
After this commit, M2Mtags translate well
OPW 784396
When fetching batched namegets (typically after a default_get), we need
to evaluate the context that we send to the server. This may be
important for models with a custom name_get method. (note: overriding
namegets should be avoided if possible)
With the new views refactoring, this was not done properly and the
'view' context was sent instead. This is not really critical, the proof
is that it took a few months before getting some complaints, but this is
definitely a bug.
To reproduce, simply add a context attribute to a m2o field in a form
view, with a non empty value in a default get, and look at the context
sent to the server.
This commit basically reverts 4974f8edb7
The fix was unstable (as restoring a feature that was not there
before release, even if originally merged before). This was in
particular breaking saas modals as lots of them are still opened
using 8.0 system... and opening them this way might make them appear
below their own backdrop in the new system the mentioned commit
restored.
We will think about that feature again for a future version.
Before this commit, there were an error when you tried
to change the view_type directly from the url in debug mode.
The controller of the view wasn't defined and a crash happened
when we tried to render the DebugManager.View.
To fix this, we now wait for the 'switch_mode' which sets
the controller to the active view.
'do_load_state' is now chained to 'switch_mode'
Before this fix, the chatter always showed dates of messages in military time format.
This was not the expected behavior, as the user could have had customize
the date and time format in the settings of the current language.
Steps to reproduce the issue:
1. Set Odoo in English
2. Settings > Translations > Languages > English
2.1. Set Date Format to %m/%d/%Y
2.2. Set Time Format to %I:%M:%S %p
3. CRM > (Select any opportunity with at least one message) > Mouse hover on elapsed time (e.g. "an hour ago")
Expected:
- It shows the customized time format (e.g. 11/07/2017 5:33:36 PM)
Results:
- It shows the military time format (e.g. Tue Nov 07 2017 17:33:36 GMT+0100)
opw-781647
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 commit, when a product category had a similar name than an other
e.g. ALL / Exp and ALL / Expenses
When entering the list view of its products, it displayed the product linked to the category with the similar name
e.g. When opening ALL/Exp products list, it displayed its products **plus** the products of ALL/Expenses
After this commit the list view just contains the active category's products
OPW 782905
Before this fix, there was an issue when you changed the value of
a datetime field by editing direclty the input (without using the
datepicker popup).
If this value was equal to the offset of your timezone,
the new value wasn't saved. The problem was that no event was
triggered by the 'bootstrap-datetimepicker' lib because it
considered that the old datetime and the new datatime were the
same...
In odoo JS, we always manipulate UTC moment objects and we
manually add the timezone offset at rendering (we mainly do that
for testing purposes). When the offset is added, calling format()
on the moment object doesn't convert the datetime to the browser
timezone because it's flagged as being UTC.
The datepicker lib creates moment objects in the browser timezone.
So comparing the ones it creates with the one given by Odoo is
like comparing apples and oranges, and it gives wrong results
when the datetimes differ by the exact timezone offset. So in this
case, no 'datetime change' is triggered by the lib.
We could fix this by wrapping moment objects into some kind of
OdooDate class and stop manually adding the timezone offset, but
this would involve a refactoring that can only be done in master.
Instead, we prefered to patch the lib to ignore the comparison
between UTC and non-UTC objects, as this is the safest way we
find to fix this issue in stable version.
Mixing positive and negative values in a pie chart is not possible.
However, in this case, a crash occurs instead of displaying an error
message.
opw-786137
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 event in this very specific case
OPW 777042
Due to a previous commit (@d2e1a1de), if a date was selected in
search filter, the time was converted to UTC to the server.
For negative offset, the search was then executed for the day before.
Now, we avoid to convert the searched date to UTC.
We only need to convert datetime fields.
Before this commit, it was not possible to choose the user you want to
chat with in a chat window anymore. This was because the dropdown that
suggest the users appeared under the chat windows since commit
https://github.com/odoo/odoo/commit/7b965a9673a9124e6e045b8a290a156eed402ad5
Indeed, the mentioned commit changed the z-indexes so that chat windows
are still usable when a modal is opened. This was done by making the
chat windows always have the greatest z-index... forgetting this would
make them appear on top of their own autocomplete dropdowns.
This commit restores the feature while keeping the ability to talk while
a modal is opened. See code comments for details.
opw-785162
When grouping a graph view by a selection field, the labels on x axis
were the selection values themselves (not their corresponding label).
This issue was only present if there was only one group by field. In
this case, the attribute `grouped_on` is not an array but a string
containing the field name. This case wasn't correctly handled.
Note that this issue is not present in the new views (from saas-16).
Closes#19790
When a datetime was selected in a search filter, the time wasn't
converted to UTC to the server.
So, there were unexpecting records due to the wrong query domain.
When we retrieve the value from the datepicker, we need to convert
it to UTC before sending it to the server.
Most field widgets are synchronous, but some of them have to do extra
work before being ready (for example, the pad widget, or widget which
needs to lazy load JS/CSS files). Because of that, the new views have
been well tested with synchronous widgets, but not completely with async
widgets.
Some code depended upon the fact that the widget was ready immediately
after being created. This was incorrect, and is fixed in this commit,
by adding a new hook that is called in (basic) views after a widget is
ready (meaning, start and willstart are done)
Example of failing request:
```
rpc.query({
model: 'link.tracker.click',
method: 'read_group',
args: [[links_domain, ['create_date', '>', interval]], ['country_id']],
kwargs: {groupby:'country_id'},
});
```
The RPC request built contains the following:
```
args: [[["link_id", "=", 1]], ["create_date"]]
kwargs: {groupby: "create_date:day", domain: [], fields: []}
```
This will be interpreted server side as:
```
model.read_group([['link_id', '=', 1]], ['create_date'], groupby=['create_date:day'], domain=[], fields=[])
```
2 arguments match `domain` and `fields`, which causes a crash.
opw-781300
on pricelist, open a pricelist form
click on one country group [country group form opens]
click on a pricelist again
Before this commit, a traceback appeared, saying the pricelist record was null
YET the pricelist's form on which we clicked before opened.
After this commit, the form of the pricelist opens, and no traceback is thrown.
OPW 783896
[FIX] web: test circular many2many
closes#21148
Since odoo/odoo@da136d8 the modifiers in the widget attrs are parsed.
`stringify` thus needs be to used when displaying them in the debug tooltip (to
avoid to display [Object object]).
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 attribute `autocomplete` is set with the jQuery function `attr` but
the test was using the function `prop`.
This seems to work in Chrome but apparently not in Firefox.
Consider the following situation: a form view with a one2many which
contains sub x2many fields (for example a m2m_tags). Suppose that the
one2many has more than 40 records. Before this commit, trying to delete
one of these records caused a crash.
The reason is that when we delete a record, we need to reload the
missing records in the one2many field. We actually do that with a
_readUngroupedList. However, the _readUngroupedList method did not
process x2many fields, so the information stored in the datapoints was
'raw', and the rest of the web client expected it to be a datapoint.
To reproduce the issue in the testing environment, i had to use
onchanges and a readonly attrs, to reach a situation where a crash could
occur. This shows that, while the issue is critical, it was not totally
trivial to be impacted by it.
Before this commit, the 'limit' attribtue worked properly for list views
(but was not documented), and was ignored for inline tree views. There
was no good reason for that limitation, so we fix this issue.
When logging multiple elements in one log call in the new Firefox
version, all the elements are kept on one line. So if the second
element starts with a line feed, it will not go under the first
element but still be at the right of the first element, on a new
line.
If the kanban view is grouped by a readonly field, it should not be possible
to drag&drop the record from one column to another as this will trigger a
write on this readonly field.
It should however be possible to resequence records so the option `containment`
is used in the records.
Closes#19390
Before this fix, when adding the attribute delete=0
on a listview, it was still possible to delete records
via the menu 'Delete' in the sidebar.
After this fix, this should not be possible to delete
records when delete=0.
The attribute delete was hard-coded to true, as there was
a traceback when it was set to false. It was simply due
to a misplaced closing brackets that was hiding an
assignment, which resulted to calling a method on undefined.
Before this fix, when adding the attribute delete=0
on a listview, it was still possible to delete records
via the menu 'Delete' in the sidebar.
After this fix, this should not be possible to delete
records when delete=0.
The attribute delete was hard-coded to true, as there was
a traceback when it was set to false. It was simply due
to a misplaced closing brackets that was hiding an
assignment, which resulted to calling a method on undefined.
Lucas Perais (lpe)