Due to these commits, it was impossible to make an uninstall_hook
just after an uninstallation.
In some case, it 's needed to make an uninstall_hook just after the uninstallation.
Look this commit for example: e03c919e9955c5d3f678c0580744d9ef8c483c74
- Create a partner with an invoicing and a delivery address.
- Connect to the website as this partner, create an order
- In the "Shipping & Billing" page, the delivery address is selected
automatically. Change and set to "Ship to the same address", and
confirm.
The "Ship To" address is still the delivery address, while it should be
the same than the "Bill To" address.
This reintroduces the v8 behavior:
`order_info.update(partner_shipping_id=checkout.get('shipping_id') or partner_id)`
https://github.com/odoo/odoo/blob/8.0/addons/website_sale/controllers/main.py#L623
Create the following
- Create a partner of type "Company" (Address 1)
- Add an "Invoicing" address to this partner (Address 2)
- Add a "Contact" address to this partner
- Authorize this contact as a portal user
Connect as the portal user created:
- Place an order from website, add a product to cart
- In "Shipping & Billing", confirm the order. The proposed billing
address is "Address 1". Do not change the shipping address ("Ship to
the same address"), and confirm.
The "Bill To" as well as the "Ship To" address are set to "Address 1".
This is a regression from v8. In v8, "Bill To" is set to "Address 2",
while "Ship To" is set to "Address 1".
opw-707283
The variable `st_line` was used outside of its scope,
in the line
`move.line_ids.filtered(lambda x:x.statement_id == st_line.statement_id).write({'statement_id': False})`
It leaded to issues when calling the method
on multiple `account.bank.statement.line`: Only
the items associated to the last line were unlinked
opw-709196
Links containing HTML escaped characters,
such as the ampersand
`&` escaped `&`
were not shortened correctly:
Their redirecting URL contained the escaped value
(e.g. `&`) instead of the actual character,
leading to the wrong redirected URL.
e.g. creating a mass-mailing with a link
contains as query string
?test1=1&test2=2 were shortened
with as redirect link
?test1=1&test2=2
opw-708272
Without passing `active_test=False` in the context,
a one2many fields exludes the record with
`active` set to False.
For an archived product template, this means
`product_variant_ids` returned an empty array
opw-708828
When clicking on the smart button "Claims" of a contact, it shows
a tree view with all the claims of this contact and his children(because
the domain on the filter is [('partner_id','child_of',self)]).
So the function _claim_count has to return the sum of the # claims
of a contact and the # claims of the children of this contact.
opw:708698
For a pricelist based on another pricelist,
the price of the product is the price in this other
pricelist.
To get the price of a product in a specific pricelist,
the field `price` must be used, along with the right `pricelist`
passed in the context when browsing the product.
Without this, the sale price is considered the sale price
indicated on the form, in the product company currency,
while the pricelist on which is based the currenct pricelist
could give a specific other price, in another specific currency.
e.g.:
Watch, Sale price 690CHF
Public USD Pricelist, setting the sale price of the watch to 790 USD
Reseller USD Pricelist, discounting 60% based on the public pricelist price, discount shown.
Before this revision, the sale price of the watch was marked
690 USD, with a sown discount of 54,xx %
With this revision, the sale price of the watch is marked at
790USD, with a shown discount of 60%, as expected.
opw-708301
Backport of 1f6ec2b8d6
When the quantity of a purchase order line is manually decreased and if
the purchase order line as been generated by more than one procurement.
If the new quantity is lower than the quantity of the smallest
procurement, it is impossible to validate the picking containg the
stock_moves created by the purchase order validation.
It is impossible to validate the picking, because it contains
stock_moves with 'product_qty' set to 0. Those stock_moves are generated
during the validation of a purchase order.
To fix this issue, we avoid the creation of stock moves with a
'product_qty' set to 0 which has no sense.
opw:708099
2 sequences are created when a pos.config is created:
- one for pos.order, stored in sequence_id field
- one for pos.order.line, link is lost, like dust in the wind ♫
When creating a pos.order.line from a new order, the default value was using the
first sequence if found using the code 'pos.order.line' (returning the latest
created).
The name of the line was always using the same sequence, whatever the config
used.
In master, the field has been stored at 645df676 but in stable version, the
following hack is done:
As the sequences are created in the same transaction as the pos.config, the
create_date will be the same to the microsecond.
The name of the config can not be used as too easily changed (e.g. duplicate)
and may not be unique.
Done in SQL to avoid ORM cleaning of microseconds, not working with a search.
opw-703092
When creating an invoice from Purchase Order(stat button) if you do not have a journal of type 'Purchase' defined for current user's company, it will crash.
Use case:
Company is in USD, create a bank journal in euro and set euro currency to 0.9
Create invoice for 80 EUR and pay it. Then create a bank statement of 85 EUR in newly created journal and use reconciliation widget to reconcile statement and payment. Put the remaining 5 EUR as writeoff in bank fees. The move created for those 5 EUR wrongly computed the amount_currency of the counterpart, this commit fix this problem.
OPW: 706708
PR #15306
Without this the first account.move.line will be generated with the
currency rate valid at the time of validation. The following lines
however will be generated with the currency rate valid at 'date' of the
voucher. If these currency rates are different this results in an
unbalanced journal entry.
This ensures the first account.move.line will also use the currency rate
at 'date' of the voucher.
If not account.voucher will attempt to generate an account.move.line
record with a set amount_currency and an unset currency_id. This is
explicitly forbidden by account.move.line's _check_currency_and_amount
constraint.
Steps to reproduce:
Go to any pivot view (for example Sales > Report > Sales) and add
the current view to your personnal dashboard (in the search view: Favourites > Add to my Dashboard)
Go to the dashboard, traceback because $buttons was not defined.
opw:707296
When tax_calculation_rounding_method is configured to round_globally the
compute_all method of account.tax will not round the taxes based on the
currency. The result of the compute_all function is used when creating
the tax parts of a pos.order account.move.
Taxes are aggregated per session, so 2 orders with orderlines in them
with the same tax will turn into 1 single tax account.move.line. To
correctly handle round_globally, we round all tax values we have after
processing each order.
Fixes#14672Fixes#14673
In revision fc813847d8,
`_compute_total_invoices_amount()` was assumed to
give the invoice residual within the company currency but,
in the case the payment_currency is different than the company_currency,
it returns the amount in the payment currency.
In this case, we actually need the total invoices residual
within the company currency.
The amount of the invoice in the payment currency was wrongly
computed when a change of rate in the invoice currency occured between
the invoice date and the payment date,
when the invoice currency was neither the company currency
nor the payment currency.
e.g.
Company in USD. Exchange rates:
07/02 08/02
HKD 7.0 8.0
EUR 0.90 0.94
Invoice: 100,000 HKD, date 07/02, worthing 100,000 / 7 = 14285,71 USD
Payment: 13000 EUR, date 08/02, worthing 13000 / 0,94 = 13829,79 USD
The invoice amount within the invoice currency was computed:
100,000 / 8 * 0.94 = 11750€
While the invoice, at the time of the invoice date, worth actually
14285.71 * 0.94 = 13428,57€
When the invoice, payment and companies are all different,
the invoice amount in the payment currency must not be computed from
the amount in the invoice currency computed at the invoice date
to the payment currency, since the rate of the invoice currency
changed, and the amount in the invoice currency at the time
is no longer the same today.
In simple words, `amount_currency` of the invoice
was computed using the 7.0 rate
e.g. 100,000 / 7 = 14285,71
while, when the rate changes, computing from the invoice currency to
the payment currency, which are both different than the company currency
it will first convert the amount to the company currency, using the new rate:
e.g. 100,000 / 8 = 12500€
and then convert to the payment currency:
e.g. 12500 * 0.94 = 11750€
opw-640248
In SQL, if there is no quote around the table/field, the result will
be returned as case insensitive.
This was causing a bug in the kanban view which was not displaying
the records because x_AA_count was named x_aa_count.
When opening a purchase order shipments using
the given smart button, and attempting a refresh,
it leaded to a "record has been deleted" error,
because the current `active_id` is a purchase.order
id, while the `active_id` in the window action
`action_picking_tree` context expects a picking type
id.
The purpose of using `action_picking_tree` was to use
it as a template instead of having to create a full action
dict, not to actually use it.
By removing the id from the action dict, we prevent
to re-use the action window `action_picking_tree`
on refresh.
opw-706933
In debug mode the buttons "export unpaid orders" and "export paid orders" now
work. On first click, they prepare the file and display the download link. On
second click, the file is downloaded.
The error popup uses the same method to download the traceback.
Use a different icon to have a visual feedback why that 2 clicks are needed.
This 2 steps is required as it is not possible in most browsers to simulate a
click event on a link.
The download method is kept for backward compatibility but will be droped in
master.
In the next version, a proper popup will be integrated (cf #14365)
Closes#15322
The POS uses FastClick to circumvent the 300ms touch delay implemented
by browsers before a click event is fired. (Although this has since been
removed, probably we can get rid of this in the POS at some point as
well [1]).
The way FastClick works is simple: immediately fire a synthetic event
and block the one fired by the browser 300ms later.
Recently, browsers have started to only trust native events to trigger
default actions [2][3]. Chrome in particular has started not trusting
synthetic events since v53.
FastClick provides a solution for this with the needsclick class. It
will not interfere with events triggered on elements with this class.
[1] https://developers.google.com/web/updates/2013/12/300ms-tap-delay-gone-away
[2] https://w3c.github.io/uievents/#trusted-events
[3] https://www.chromestatus.com/features/5718803933560832Fixes#14886
This record rule added in the below revision:
1950fc4216
has been removed for an unknown reason during the account refactoring
c04065abd8
Without this rule, a user can see invoices from other companies
through the invoices analysis.
opw-705718
This is related to revision
52db42d3df
The total sent to the `compute` method is always
within the invoice company currency, not
in the invoice currency.
`total` comes from the first tuple result
of the method `compute_invoice_totals`,
which is always in the invoice company currency.
if the company currency is different than
the invoice currency,
the total is the sum of the `line['price']`
converted to the company currency, as stated
by
`line['price'] = currency.compute(line['price'], company_currency)`
and
`total += line['price']`
In the above revision, the possibility to pass
its own currency in the context is added. This is in case
the payment term used comes from another company
than the one of the invoice (see the commit message of the revision).
The mistake was to use the invoice currency, while it should
use the invoice company currency, as the `total` amount is
within the invoice company currency, not the invoice currency.
opw-705604
Goffin Simon