The 'help' of window action is often fiddled with, adding thing before,
after or arround it.
For example in CRM leads, we add at the beginning "Click to add a new
opportunity" with an arrow towards the button, and after if there is a
mail alias: "All email incoming to * will automatically create new...".
But for crm.lead, hr.expense, sale.order this would not take into
account that the fiddled "help" can be edited, so if we edit 2 times
help in studio or backend action editing, we would get:
Click to add a new opportunity
Click to add a new opportunity
Click to add a new opportunity
[Original help content]
All email incoming to * will automatically create new...
All email incoming to * will automatically create new...
All email incoming to * will automatically create new...
And see several "arrows" towards the button (in enterprise the
additional ones are on same color background).
With this commit we do what is done in "mail.thread" by default which is
not fiddling with the `help` if has been fiddled before (if it contains
"oe_view_nocontent_create" class).
note: this is the 11.0 version of #26912
opw-1877663
closes#26911
Due to this commit: b367625248
The function "_get_payment_type" was not defined in module "sale_payment" but defined in "website_quote"
The bridge module for "website_quote" and "sale_payment" is "sale" so the first definition of "_get_payment_type"
must be in "sale".
opw:1881990
Some users are confused by the generic error message asking to confirm a sale
order that is in locked or cancelled state.
We add specific error messages in these two cases.
opw 1871019
When accessing a quotation from an email link, no action is given.
As a result, after create/discard of a new record, the abandonRecord method does
not find a fallback page to go to, and it appears as if the discarded new record
had been created.
opw 1869350
11.0-opw1869350-action-len
Steps to reproduce the bug:
- configuration on sale:
- Unit of measure: Some products may be sold/purchased in different units of measure (Advanced)
- Sale Price: Advaced pricing based on formulas (discounts, margins, rounding)
- Discount: Allow discounts on sale order lines
- kg as the Reference UOM for weight
- create an uom 10 kg
- Category: Weight
- Type: Bigger...
- Bigger ratio: 10.0
- create a product P
- Sale price: 100
- Unit of measure: kg
- Purchase UOM: kg
- create a pricelist "My pricelist"
- Discount policy: Show public price & discount to the customer
- Items : All products - 10% discount
- create a SO with "My pricelist"
- create a SO line with P, the unit price is automatically 90 with 10 % of discount
- change the uom of the line with 10kg
Bug:
The unit price of the line didn't change and the discount on the line disappeared.
In function product_uom_change, the uom of the SO line has been set in the context
of the product(like in function product_id_change). So in funciton _get_display_price,
the function _get_real_price_currency must be called with the uom of product in the context.
In this way, the lst_price will be fetch on product with the right uom without any bad conversion
(because uom.id == product_uom with uom from the parameters and product_uom from the context).
But with function get_product_price_rule, no need to call this function with the uom in context as
it is already set in the product(check "if uom_id: ... else ..." in this function).
The same logic has been applied in function _onchange_discount
opw:186385
The commitment date is computed using every line from the sale order.
When the picking policy is set to direct, it takes the earliest date
among the sums of the order date and lead time.
However when the delivery is set, is adds a line with an order date of 'now' and
no lead time.
This date thus necessarily becomes the commitment date, bypassing what was
intended by setting a lead times on products.
We simply ignore delivery lines in this computation.
opw 1855646
Before this commit, the discount on a so line was always brought to zero when changing the price
After this commit, we do this only when the pricelist is supposed to compute the discount
OPW 1867262
closes#25851
When archiving a product template P with one SO linked to it,
- Going to P by Accounting > Configuration > Products > P shows 1 sale
in smart button
- Going to P by Accounting > Sellable products > P showed 0 sale in smart
button
Now it shows 1 sale in these two cases.
opw:1852948
When manipulating domain, this is always better to
normalize them, otherwise we can have strange behavior
when handleing them with `expression.OR` and
`expression.AND`.
For instance:
domain = [('so_line', 'in', [91]), ('amount', '<=', 0.0)]
timesheet_domain = ['&', ('so_line', 'in', []), ('project_id', '!=', False)]
`expresion.OR(domain, timesheet_domain)` will give
['|', ('so_line', 'in', [91]), ('amount', '<=', 0.0), '&', ('so_line', 'in', []),
('project_id', '!=', False)]
And this is not what we attempt.
Closes#24038
The sale_note field is translated according to the language of the customer in a SO.
This fix applies the same behavior on the customer invoice.
Inspired from this commit: 978b8f64ec
opw:1830838
This commit format the display_name of sale.order.line,
without context key.
The webclient trigger the name_search with context
key, but display the field without it.
So on task form view, when searching an SO line, user
will see 'SO0001 - my product' in its dropdown, but the
complete SO line description when saving.
This commit proposes, in aggreement with AL and FP, to
a global (and non conditionnal) format, since it seems
task form view is the only one place requiring the SO
line name_get.
Before this commit, the smart button on the SO was computed
with only the SO's name field
In a multicompany setting, it could give up invoices from other companies
After this commit, only the invoices of the same company as the order are accounted for
OPW 1831551
closes#23925
Steps to reproduce the bug:
-Create a tax of 21% tax included but don't select the "affect base" checkbox.
-Create another tax of 5.2% (no tax include)
-Create a sale order with a line that has a unit price of 121 and both taxes.
Notice that the total amount is: 126.2 (100 base amount + 21 from 21% tax + 5.2 from 5.2 tax)
-Click on "Print the proforma invoice"
Bug:
The total amount was still 126.2 and base=100, however taxes were wrong, there were 21 for the 21% tax
and 6.29 instead of 5.2 for the 5.2 tax.
Back-port of this commit: f50a08bc3d
Forward up to saas-15
opw:1819882
Steps to reproduce the bug:
-Create a tax of 21% tax included but don't select the "affect base" checkbox.
-Create another tax of 5.2% (no tax include)
-Create a sale order with a line that has a unit price of 121 and both taxes.
Notice that the total amount is: 126.2 (100 base amount + 21 from 21% tax + 5.2 from 5.2 tax)
-Click on "Print the proforma invoice"
Bug:
The total amount was still 126.2 and base=100, however taxes were wrong, there were 21 for the 21% tax
and 6.29 instead of 5.2 for the 5.2 tax.
opw:1819882
Nicolas Lempereur