The previous code (`parent.field_widget.string`) was returning the untranslated
action name (and why use parent anyway?)
Use the action name instead.
Closes#15207
opw-705938
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
With a sale order with:
- a stockable product
- the `Create Invoice` policy set to `Before Delivery`
After the quotation validation and the invoice validation,
if the user:
- cancelled the invoice,
- then validated it again,
- then hit `ignore exception` on the sale order
- then registered the payment on the invoice
The picking of the sale order was not created automatically,
and the sale order was therefore stuck.
Actually, it was just a write trigger that was missing:
The condition for the sale order workflow to go to the next state
is that the `invoiced` boolean is set to True.
It was, when the invoice of the sale order was paid
(after having registered the payment), but since
this is a computed field, not stored, no write operation
was actually performed on the sale order, and the workflow
wasn't "notified" that a change occured for the `invoiced` boolean.
A simple write on the sale order (e.g. in its notes) would
have unblock the situation, though.
This trigger ensures the worfklow to be notified when
the invoice of the sale order is paid, and therefore
when the `invoiced` boolean is set to `True`.
opw-706591
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
A byproduct is a produced when producing another product (the targetted
product).
A move can be linked to another move. eg: we could have a manufacturing
order of 3 units linked to a move of a delivery order of these 3 units.
If we produce 2 units, the manufacturing order is split in 2 units and
1 units, and the delivery order is split similarily because of the link
1. [T manufacturing move split] -> [T delivery move split]
(T is the targetted product, B is the byproduct)
But in 8c307d7b1 a move_dest_id of a byproduct was linked to the targetted
product delivery move, thus in some situation the move of the delivery
order of the byproduct would erroneously be split 2 times instead of one.
1. [B manufacturing move split] -> [T delivery move split]
2. [T manufacturing move split] -> [T delivery move split]
This could also be the source of other issue, and since the byproduct
and targetted product are different, the link should anyway not be done.
opw-697151
note: this change is already in 10.0 (it is inside mrp refactoring 2ddc35a53)
The field 'Type' should always be readonly since:
- it must not be changed for standard models
- its value must be 'Custom Object' for a custom model
opw-706130
When editing translations, you were not able to copy/paste texts before
this commit. Indeed, in some contexts, in some browsers, copy/pasting
text was creating a new paragraph inside the translation, preventing it
to be saved.
This commit simply adds code to remove these paragraphs each time text
is changed.
A more elegant solution will be found for master with website and
editor improvements.
When the quantity on hand is updated from the wizard, it may result in
completely inconsistent results.
This happens for example in the following case:
- 10 Units in Stock/WH
- 18 Units in Stock/WH/Shelf 1
The "New Quantity on Hand" suggests a theoretical quantity by taking
into account the location and its sub-locations. It the example, that
would mean 28 Units in location 'Stock/WH'.
However, the `_get_quants` method of the `stock.inventory.line` model
doesn't take into account the children locations. Therefore, the
theoretical quantity would be 10 Units in location 'Stock/WH'.
This inconsistency confuses the user, and the new quantity added might
introduce unexpected results.
opw-703886
Before this commit, when changing measures from the favorites menu (by
selecting a filter with some pivot_measures), the measures in the
dropdown menus were not correctly updated.
This commits make sure that we update the active measures in the menu after
each changes coming from a do_search.
In some instances we could want to access the barcode without being
connected.
For example if we print the report in an scheduled action, the report
would be rendered by wkhtmltopdf as public user making the barcode
blank (we have a redirection to a html login page instead of the image).
A solution requiring view updates in stable version was implemented with:
https://github.com/odoo/odoo/commit/14282f165 in 8.0 ( further explained
in https://github.com/odoo/odoo/issues/10621 ).
This commit fix this another way in 9.0 by making the barcode route
public since this doesn't bring any harm, solve this issue and allow the
use of the barcode route for public user (which might be wanted).
opw-694470
Odoo Translation Bot