Before this commit, an opp created from a contact via the portal was assign to
himself instead of the commercial_partner_id.
So the saleperson was not assigned to the opportunity, and the opp created was
not for the company but for the contact only.
That make sense to share the opp to the company and assign the saleman directly.
Thanks to GBR for the reporting.
Use case to reproduce:
- Set a product to be expensed
- Set the expense_policy to something else than no
- Do a delivery order with a picking
- Validate the picking
-> Delivered quantity to 0 and impossible to create an invoice
if the invoice_policy is delivered_quantity
It happens due to this commit 48ea59d
What does it do:
- The move could be generated by an expense.
- If the move has 'no' as expense policy thus we won't add it in the invoice
Problem we can't guess if the move come from an expense or not (limitation).
This commit add an onchange on can_be_expense is order to set the expense
policy back to 'no' when the user uncheck it.
Courtesy of amoyaux
opw-777139
When opening the POS in this specific case:
- Under Mozilla Firefox
- auto printing the receipt is True
- invoicing is True
Before this commit, when issuing an invoice for a customer, a Traceback was thrown to the user and the invoice was not downloaded.
This was because the invoiced parameter resolved before the printing action was.
After this commit, we constain the invoiced parameter to be resolved when the action returns.
There is no traceback, and the invoice is downloaded
OPW 777647
closes#20570
- Create a tax:
Fixed amount: 10
Price included
- Add it by default to a product costing 100
- In a SO/PO/Invoice, add 2 units of the product
The total price is 210 instead of 200.
opw-779696
The `sale_stock.tour` failed in the case the admin was not
part of the group
`product.group_stock_packaging`
or the group
`sale.group_mrp_properties`
because then the sale order was working with the editable list,
which does not open a dialog,
while the test was relying on the dialog to be opened,
in order to close it.
The fix is simply to pass the fact to close the dialog if
there is none.
opw-779308
In Enterprise:
- Go in Settings > Technical > Mail > Templates
- Edit a template
- In the editor, upload an image
- Choose "Upload image without optimization"
You are sent back to the app switcher.
opw-778918
Do not try to run `action_assign` on the next move if it is done or
cancelled. The issue is that `action_assign` will first unlink the
existing pack operations before creating new ones, and the system
forbids to unlink these ones.
To reproduce this issue:
1. Create a product, routes manufacturing and MTO
2. Create SO with that product
3. Go to DO and force assign then cancel the delivery
4. Go to Manufacturing order created and produce
opw 778897
In 7eab8e26d3 res.partner was converted
to the new API, at that point company_type was changed from a stored
field manually synchronised with is_company (through create/write
overrides) into a proper computed field.
However to make it "editable" it was simply marked as
"readonly=False", which means even though UI-wise it looks editable
editing it does not actually do anything (things work in the partners
form because there's also an onchange which updates is_company on the
fly).
Fix by implementing an inverse function and actually do this
correctly.
Fixes#20623
- Go to Maintenance Requests, Create
- Go to 'Equipment' field, 'Create and edit'
- Go to 'Product Information' tab
- Click on 'Vendor' field, 'Create and edit'
'Is a Vendor' field is False
opw-779200
Fields `amount_type` on `account.tax` and `account.tax.template` are
already defined in the `account` module.
Redefining them here (with the same parameters) breaks every other
module that would have used `selection_add=` on those fields.
Actually, it is the case in `account_tax_python`, and thus, all the
localizations/customizations that depend on it were broken by this one.
~ Old API backport of 5d0d80afa5 ~
Fields `amount_type` on `account.tax` and `account.tax.template` are
already defined in the `account` module.
Redefining them here (with the same parameters) breaks every other
module that would have used `selection_add=` on those fields.
Actually, it is the case in `account_tax_python`, and thus, all the
localizations/customizations that depend on it were broken by this one.
(issue spotted by 11.0-nightly)
Closes#19812#20596
Remove weird special case: when the first field of the first line of a one2many
is empty, replace this first field by the comma-separated names of the lines,
and discard the other lines.
Fine tuning of this commit: 51d072db44
When clicking on the group of the Inventory at Date, the
product.price.inventory must follow the same order as the
read_group in stock.history.
opw:747857
Before this commit, many2one fields were not (fully) usable in a list view: if
the user wrote some text, then when a dropdown with various choices
opened, pressed the 'down' key (to select a choice), the down keypress
caused a navigation move to the next line, which cancelled the
selection.
In this commit, we make the assumption that if the many2one dropdown is
opened, then navigation moves are not what the user wants.
- Create an asset, post one line.
- Go back to the asset => the button is green
- Click again on the line => the button is orange
There is no protection to prevent the user to post the same entry
several times (a new account move is created every time it is clicked).
We fix the JS widget, but we add an extra layer of protection at the
Python level.
opw-778756
Commit b131e9b0ef changed the way the keypress event was bound from vanilla JS to JQuery
In the pos, since it cleans up every jquery event for performances' sake, this binding was cancelled.
This commit cleans up the cleanup process of event at pos startup and rebind the keypress event to the now clean body.
OPW 778565
[FIX] point_of_sale: barcode bindings other strategy
closes#20535
Before this commit, when trying to access website_public_price from the backend (when adding this field to a view for example), a traceback saying that the website attribute on the request object was non existent was raised.
After this commit, we control for this and the field displays correctly
OPW 778586
closes#20536
Before this commit, when opening the POS in IE11, then the customer list, the list was empty.
This was due to condition that was wrongly evaluated as false due to the fact that IE11 apparently only wants ECMA5.1 to deal with constructing Date() from a string.
After this commit, we construct the Date() object with the right string, and the list of customers doesn't disappear.
OPW 776463
For reference:
http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.1.15closes#20468
When evaluating a domain, each x2many in the evaluation context is
actually replaced by a list of ids. However, previously, it was actually a
list of commands. The list of ids is much better, since it does not
depends on the exact commands that were generated.
Taxes tags for some localization have been rewrote in order to improve the taxes report.
However, these changes delete the existing account.tags on stable version.
These "[l10n_*] one tag per grid in tax reports" should target master instead of 9.0.
-opw: 777464
When an onchange fails (for example, because the onchange python code
raised a ValidationError, it is convenient to revert the form view to a
valid state, which is the previous state.
To do that, we keep in the _applyChange function the initial state, and
restore it in the case the onchange fails.
In some cases, vendor reference for payment may already exists.
For instance in Belgium, some suppliers provide recurring invoices which
contain the same communication for the payment. From the version 9.0,
the field Vendor refrence is used for payment communication and the
maching on bank statement.
So, in this case, we have to put the communication from the payment in
this field and, as explained just above, maybe the same as on another
invoice.
Therefore, this commit provides a hook to modify/disable this behavior.
Closes#20343
opw-777608
Jeremy Kersten