based on v10 terms and saas-15
add the new languages
Much noise due to the different softwares that do not indent the terms the same
way. Merged the po files with --no-wrap option which makes long lines.
opw-751014
If you have two invoices with a same product,
- one having 1 unit of a product,
- the other -1 unit of a product,
The sum of these quantities will be 0, and it will lead
to a division by zero in the former sql request.
The nullif should be applied on the sum, not on the line quantity.
opw-745073
Because read_group can not handle non-stored fields well,
we fall back to the similar implementation as for the stock
valuation report. This allows only one non-stored field as a measure in
the graph. Then it is more logical to show the total margin as that is
what the module is meant for.
All the fields defined in model "product.product" from module product_margin
are computed and not stored with the same function which is _compute_product_margin_fields_values.
This function has a deprecated argument which is field_names and this agrument is only used in
function read_group overwritten in this module in model "product.product. This overwrite of
read_group uses a variable "fields_list" with almost all the fields defined in "product.product"
in this module (excepted: date_from, date_to and invoice_state which are read from the context).
Each time, the fields total_margin, expected_margin, total_margin_rate, expected_margin_rate,
date_from, date_to, invoice_state were needed, nothing was returned due to the empty argument
field_names passed to this method. For example, when opening product.margin.form.inherit form
view.
In old API, it works because the compute was called with the list of the fields and in new API, it is not the case.
Closes#15604
opw:709962
Trying to use "group by" in the product margins menu creates a traceback with a keyError.
The problem is that the function stores a recordset in the dictionary and then tries to
get it back with an integer.
This commit solves the problem by storing the product id in the dictionary instead of
the product itself.
Previous commit was cleaning the orphan and fuzzy translations of all main translations.
This commit does the same for all regional languages (that are not on Transifex).
To keep these files small, keep only the translated strings.
Fixes#14937
Some languages were published on Transifex in v9 but no longer in v10.
These languages were still using the outdated .po files
In some of these po, there were some fuzzy translations that were incorrect
(e.g. 'POS Order %s' - 'Kassa ostud', missing '%s')
These were not erased as still using the old translations.
Regenerate a correct .po file based on the new .pot and remove fuzzy
translations.
Fixes similar issue than raised at #14937
Martin Trigaux