Have the main company (A) with the public user
Have an invoice in company B
Make a brand new browser access the invoice with the token
Before this commit: the token link ended up asking the customer to login,
eventhough it wouldn't if the invoice were in company A
After this commit: the whole payment with access token flow works as expected.
OPW 1879999
closes#26744
It was already present in the accounting and purchase application but not in
sale menus.
Apply the same logic as in purchase and use a group_no_one
Closes#22862
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
- Activate analytic accounting
- Create a SO, validate
- Edit, and in the tab 'Additional Information' set an 'Analytic
Account'
- Save
The analytic account is not saved.
The domain applied on the field is:
`attrs="{'readonly': ['|',('analytic_account_id','!=',False),('invoice_count','!=',0),('state','=','sale')]}"`
This means that once the account is set, the field becomes read-only.
However, a read-only field is by default not sent to the server.
opw-1882448
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
Related to f89d4201c7
Since the invoice policy is becoming more and more simple, it is
always nice to add as much logic as possible to make things even more
simple.
For the record, 5 fields are taken into account when it comes to
invoicing policy:
service_policy
service_type
service_tracking
invoice_policy
expense_policy
They are partially linked one with the other, and not all make sense for
a given product type...
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
- Activate the Sale option 'Tax-Included Prices'
- Create and print an invoice
=> the total is displayed on each line
- Activate the Sale option 'Sections on Sales Orders'
- Create and print an invoice
=> the total is NOT displayed on each line
The option 'Tax Display' only applies to SO, not to invoices. Moreover,
we make consistent the wording.
opw-1856623
Access a SO with the access token, without being logged
Before this commit, the images of the so lines were the no image placeholder
This was because the route of the image was so.line/product_image
Since the token applies on SO, and not on its lines, nothing simple would work
After this commit, we hide the image if the user is the public one
OPW 1868916
closes#25973
Courtesy of Juan José Scarafía, ADHOC
The quality of the Spanish (Argentina) translations is very poor.
Remove them all and will start from scratch, translating only when needed.
Odoo Translation Bot