| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Regarding of the `display_default_code` context value, `display_name` is
supposed to return the product code or not, eg:
> product.display_name
> '[FURN_6666] Acoustic Bloc Screens'
> product.with_context(display_default_code=False).display_name
> 'Acoustic Bloc Screens'
But since the context was not considered when accessing this field, it would
always return the cached value, which was set from the first time that field
was read, with the `display_default_code` value used at that time.
tl;dr: `display_name` was ignoring the context once cached.
One of the critical issue was that internal code were displayed on the eshop
cart (not the eshop itself), see `name_short`.
task-2517830
closes odoo/odoo#70727
X-original-commit: b5b4d38adf1f3960cda21b795a26e67b978b2901
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
|
|
|
|
Make `seller_ids` `depends_context` of company to
avoid shared cache with different company. The purpose
is to avoid making a SQL search for each `_prepare_seller` and use
the ORM cache (which depends of the company in env).
Also change the `_order` of `product.supplierinfo` to be
determinist and consistent with the `_prepare_seller`.
task-2439019
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commit ed17f560fa06e2d1c9e7495c9a4cbfe1cea5bce6 which
introduced a check not needed anymore as the field measure_type does not
exist any more since:
https://github.com/odoo/odoo/commit/52ed0be17e80aa6bcc24d59620dd3462b6d577c3
opw-2482554
closes odoo/odoo#68054
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
|
|
|
|
|
|
|
|
|
|
The function `_get_possible_combinations` generates possibles combinations
for the product template attribute values (ptav) of each product template
attribute line (ptal) of a given product template. It used to iterate over
them using a cartesian product. A combination can be invalid if it
contains two incompatibles ptav. The problem is that it used to filter out
invalid combinations after generating them. It's a problem because there
can be a lot of invalid combinations to filter out before finding a valid
combination. Even before the first valid combination if the first ptav of
the two first ptal are incompatible.
The solution brought by this commit is to reject the invalid combinations
while building them rather than after. It does so by using a cartesian
product implementation with early rejection. The algorithm tests each
ptav when incorporating it in a partial combination and if it's
incompatible, it goes to the next partial combination and thus skips all
combinations starting with the invalid partial combination.
The client that reported the issue has a product template with about 25
ptal with an average of 9 ptav. The ptav of the first ptal was
incompatible with the first ptav of second ptal. It had to build and
filter out 5.76*10^15 ptav before finding the first valid ptav. If we
generate 10^6 ptav by second (it's much less) user would get first ptav
after 182 years. Now it's instantaneous.
opw-2335936
closes odoo/odoo#65794
X-original-commit: 98616c4676aa6ef5507110c0e407a640082abbaf
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
|
|
|
|
|
|
|
|
Modifying product attributes involves discarding product variants via
the method _unlink_or_archive(), which tries to delete variants, and
archive the ones for which the deletion fails. This process is very
slow when most product variants must be archived. Instead, we filter
out the variants that must be archived anyway (like the ones used in
sales or stock), in order to avoid the variants that cannot be deleted.
On a product with ~200 variants, the time goes from more than 15 minutes
(the request times out) to around 5 seconds!
opw-2440417
closes odoo/odoo#65024
X-original-commit: 63b2f85079404eafac918a74c95e27051539c133
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
|
|
|
|
|
|
task-2409761
|
|
Courtesy of Transifex's translators for reporting bad/unclear sentences.
closes odoo/odoo#62539
Related: odoo/enterprise#15032
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
One can set a Unit of Measure precision rounding more
precise than the overall Decimal Accuracy. This can trigger the error
'It is not possible to unreserve more products', as there will be
inconsistencies on reserved quantities due to decimal roundings.
We add 2 warnings on Units of Measure and Decimal Accuracy.
Therefore, users are warned when their UOM/decimal changes can
cause inconsistencies in quants reservation.
Also, we want to prevent the issue at the root by ensuring that both the move
and the quant have the same reserved quantity.
The contrary can happen e.g. when a product is defined in Liters (rounding .001)
but used in an operation in ml (rounding .01, so e.g. 187.5ml).
The conversions between the 2 UOM can cause the differences of reservations.
In _prepare_move_line_vals we make sure uom_quantity_back_to_product_uom
is not more precise than the overall Decimal Accuracy. That way, if
the reserved quantity changes between UOM conversions, the move line created
is in the quant/product UOM, and we do not have move line's reserved quantity >
quantity in stock.
We do the same for _update_reserved_quantity (stock.move), when updating
a move line.
In _update_move_lines, because of UOM conversions, new_quantity_done
can differ from ml.product_uom_qty, which triggers the creation of an extra
move line, leading to reserved quantity > quantity in stock. To prevent
that, we compare the reserved quantities in the product UOM.
opw 2206902 (Example 1)
opw 2171541
opw 2221227
opw 2233937
opw 2198775
and many more
closes odoo/odoo#61758
X-original-commit: 91318520314632655127142de674156802214a21
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
|
|
|
|
What are the steps to reproduce your issue ?
1. Go to 'odoo.com/trial' and create a database with 'account'
or
1. Start local server with a new database and with '--without-demo=all --init=account'
2. Change main currency from 'EUR' to 'USD' in settings
What is currently happening?
Error raised when trying to install 'point_of_sale'
What are you expecting to happen?
Install 'point_of_sale' normally even after changing main currency
Why is this happening?
But there is a condition which verifies that there is not already
a pricelist with the currency we want to set or with the currency
of the company. Otherwise it prevents the pricelist modification
How to fix the bug ?
Change the condition so that it allows the change of the pricelist
in the case where the currency we want to set is not the same as the
currency of the company
opw-2376457
closes odoo/odoo#61843
X-original-commit: 716e0e791da1e4647dab29959b7012e366aa7b1f
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
|
|
|
|
|
|
This variable has been unused since commit f3d6a54e36a.
opw 2368733
closes odoo/odoo#61137
X-original-commit: 563253a8303723e3eb4217005bf518fdf6b3f9e3
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
|
|
The pricelist item model (product.pricelist.item) has a compute_price field,
and the necessary fields to be able to compute the price of a product.
However, these fields are never used into the model itself;
the parent model (product.pricelist) actually makes the computation,
embedded into _compute_price_rule.
Because of this, it's not possible to inherit pricelist items.
It's also a better design, on object principles.
Last, it lighten a method that is still 130+ lines long.
opw 2368733
X-original-commit: 9cd0bf740706a64e49599111304a6fb5ec6d7287
|
|
Courtesy of translators
Reexport .pot of modified modules
closes odoo/odoo#61002
Related: odoo/enterprise#14485
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
Except Spanish, waiting for cleanup
closes odoo/odoo#60848
Related: odoo/enterprise#14421
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
Behavior prior to this fix:
When archiving the last variant on a template, the product template
stays active (contrary to the comment indicating that `toggle_active`
will archive the related product.template if there is only one active
`product.product`).
Behavior after the fix:
When archiving the last variant on a template, the product template is
archived. When un-archiving that variant, the product template is
unarchived as well, without un-archiving the other variants.
Note: this is a remake of a fix implemented in 77e5472c041e, as that fix
did not correctly count the inactive variants.
opw-2349862
closes odoo/odoo#60635
X-original-commit: 01160ee5e7f726f3035c566a13e26825236dedfd
Signed-off-by: Nicolas Galler <nicocrm@users.noreply.github.com>
|
|
There was a problem in the Transifex translations for Spanish and all
translations were overwritten by mistake with english defaults.
This commit reverts all modified es.po files to their previous version
while we work to restore the translations on Transifex.
|
|
|
|
|
|
commit ca3e898481f4091c420a8e9ed498624a591303e9 introduce an editable view for vendor
pricelist on product variant and template.
However this view is missing product_name and product_code that are
editable field in the form view.
This commit readd them.
Fix #59099
closes odoo/odoo#59104
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
|
|
|
|
Including demo data this time
closes odoo/odoo#58821
Related: odoo/enterprise#13682
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
|
|
Improve empty screen, add sample data.
Task 2310494
PR #55910
|
|
Change the default rouning digits of all UoMs to be two, also change the
decimal.precision of UoM to be two. Adapt all the tests.
Also to avoid hardcoded digits in `should_consume_qty` widget.
PR #56000
|
|
Without demo data
closes odoo/odoo#56839
Related: odoo/enterprise#12821
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
Steps to reproduce:
- Install MRP and Inventory
- In Settings > Decimal accuracy, change the number of digits of Product Price to 6
- Go to a product template PT
Bug:
The field standard_price was displayed with two digits instead of 6
opw:2241369
closes odoo/odoo#56235
X-original-commit: cddd79b3dce31108315a7a4c6157c49fc5e97639
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
|
|
This provides a better API to search for records by name without the
formatting part (`display_name`).
This also simplifies all the overridings of `_name_search` that no
longer need to call `name_get()`. The call to `name_get()` is done in
method `name_search` in a generic way.
|
