This commit implements the same fix already made in commit https://github.com/odoo/odoo/commit/a5ca63c83beafd9a060ac58d3b4c6a9a987b28df, but this time applied to the tree view of the sale order lines, instead of the form view.
Without this fix, if you add new lines in the sale order by using the tree view (instead of the form) you can get the following error:
```
Odoo Server Error - Validation Error
The operation cannot be completed, probably due to the following:
- deletion: you may be trying to delete a record while other records still reference it
- creation/update: a mandatory field is not correctly set
[object with reference: product_id - product.id]
```
The error is because the "product_id" value is not sent to the server. The "product_id" value is mandatory for sale order lines.
To reproduce the issue, you need to reproduce the following scenario:
- create a new sale order and save it
- edit the sale order; you should be able to edit inline the sale order lines (by the tree view)
- create a new product, being sure that the field 'product_id' is readonly (field 'product_updatable' is False).
- try save the sale order
See detailed explanation of the issue in description of commit https://github.com/odoo/odoo/commit/a5ca63c83beafd9a060ac58d3b4c6a9a987b28df.
PR #21211
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
With this commit, we add a few extra logs to help debugging issues with
phantomjs.
I suspect that the recent problems with phantomjs are due to the
localstorage not being cleared properly, but the logs are not sufficient
to determine the exact cause.
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
After uninstalling an module, some actions specified in the dashboard
may not exist anymore (the dashboard view isn't correctly cleaned up).
This was causing a traceback because the dashboard was trying to load views
corresponding to an non-existing action.
Closes#19995
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.
Before this commit, it was not possible to type on a physical keyboard
the amount of a payment in the relevant pos screen
This was due to the refactoring of BarcodeEvents (commit b131e9b0ef)
which converted vanilla JS events to Jquery ones, which the pos was not ready for.
After this commit, it is possible to type the amount of a payment
in the payment screen, just as it worked in 10.0 so far.
OPW 781242
closes#21094
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.
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.
Do not forward-port this after 11.0
After sending a message, if one switched in edit mode in the form view, the
created message disappeared.
This is because the model is not aware of messages (they are created through
their own routes, message are not handled as other one2many fields with commands)
and the widget was reset with a new datapoint instance when switching in edit mode.
In this rev. we keep the model informed of the new messages by directly writing
the message ids in the datapoint.
Note that the includes on FormController and BasicModel are one in the
form_renderer.js file to fix this issue in existing database without adding
files. Another revision will be done in master to add the correct files.
opw-781353
Before this commit, asynchronous field widgets (with willStart async),
with a non empty template had a problem: the invisible modifier was not
applied properly.
The reason is that the code that applied the modifiers was called
directly after the widget was 'willStarted'. This means that if this is
async, and if there is a template, the $el in willStart will be replaced
by another $el after, which will remove the invisible modifier.
This was an interesting problem with the pad widget (it is asynchronous
the first time a pad widget is instantiated)
Because the uom field on production lot is a related field of
product.prodcut, we shouldn't change the uom of a product through the
production lot formé
Consider this: a form view with a one2many list view. In the one2many
list view, there is a many2one field. When opening the manyone in a
modal form view, there is a many2many field. In that situation,
clicking on 'Add a new record' on the many2many field had the
unfortunate effect of interfering with the one2many field in the main
form view, which caused a crash or the modal form view to close
unexpectedly.
The issue is that an event was simply not properly stopped at the proper
location. This is usually not a big deal, but, as described above, it can be
a problem in some cases.
- This commit, fixes a crash triggered when the user is paying a quote while having his browser language set to a language not defined on the Odoo database.
This is due to the fact that the field 'name' on the model 'account.analytic.account' is translatable.
Stripe sends a json query to the server with the user's browser's language on the 'Accept-Language' http header field.
By doing this, Odoo add a 'lang' key to the context, which is then used to translate translatable fields.
- Install French language
- Set language of Customer A to French
- Create an invoice for A (some tax must be applied)
- Print the invoice
The tax amount below 'Subtotal' is not formatted in French.
`t-esc` does make use of the `t-lang` option, so when the expression is
evaluated, the lang is not in the context. We do not change this
behavior since it can have a major impact.
opw-782118
- Install French language
- Set language of Customer A to French
- Create an invoice due in the past
- Open the Customer Statements
The customer statement of A is translated in French, but the amounts are
formatted in the company's user language (English by default).
We add the possiblity to take into account the lang in the context when
calling `formatLang`.
Before this commit, if you go on /shop/cart and your cart is empty, it will
show the total (Subtotal, Taxes, Total) as $ 0.00.
Indeed, the code is retrieving a 'sale.order' if you are connected and you
already have a draft sale order on DB (eg: you just add something to cart and
emptied it afterward).
- Add product to your cart and proceed to checkout
- On checkout cart, remove the product, your cart is now empty
- Reload the page (you should still be on /shop/cart) or go to /shop/cart
- You now see the zero prices (Subtotal, Taxes, Total)
Now, we will hide this if you have an order but no line on that order.
This closes#20896
The logic was not the same in function _compute_product_pricelist and in function
_inverse_product_pricelist.
The function _get_partner_pricelist must check the default pricelist for the company when
no pricelist is given for the specific partner(res_id) because the function set_multi doesn't
set a specific pricelist to the partner if the pricelist set and the default one are the same.
opw:779808
Go to Report -> Operator Analysis -> Apply group_by 'Creation date
(hour)' => traceback.
`start_date_hour` is implemented for Livechat Support Report on
Channels, but not on Operators.
opw-782255
Andrea Stirpe