Currently applying a color to a kanban item applies it to the whole
card. This creates usability issues as the content is not dynamically
updated to match the chosen color.
This commit proposes to apply the color only to the header and let the
card content standard. It helps designing cards that are always usable
and readable.
When you have push rules on move having a 'production_id', the
'production_id' is copied on the generated moves. So it generate a
traceback when we check the tracking method of 'product_id' on
produce_move.
This issue is caused because we get multiple produce_move instead of
one.
To fix this issue, we don't copy the production_id anymore on moves
generated by push rules.
In function _get_top_level_packages, when checking that all the products
have the same destination, the destinations must be stocked in a set
instead of a list because with different products it could return a list
with duplicated destinations.
opw:725720
When we validate a SO with an MTO product, then an RFQ and a delivery
picking are created. The status of the delivery picking is in state
'confirmed', but should be 'waiting' as the delivery waits for a
specific delivery input.
The problem is caused by the unreserve method, which is called in the
'procurement_jit' module. This method only checks that a move has
ancestors to determine if the move should be in waiting or in confirmed,
which is not the case for our delivery move because the RFQ has not been
validated yet so there is not ancestors yet.
To fix this issue, we check the 'procure_method' of the move, and if it
is in 'make_to_order' we put it in 'waiting' instead of 'confirmed'.
We also fixed the function recalculate_move_state that could cause the
same problem.
- Create a kit (phantom BOM), composed of 2 different products A and B
- Create a SO, sell a random stockable product, confirm and validate the
picking.
- Edit the SO, add the kit and save.
Two pickings are created, one for product A and one for product B.
Commit 8fe8ca9948 forces the recomputation of the stock moves, in order
to be able to find a newly created picking. This should actually be done
after each picking creation.
opw-725929
When you have multiplle global push rules with the same source location,
a traceback is raised because the '_apply' method of
"stock.location.path" is called with more than one record, and doesn't
handle multiple record.
To fix this, we limit the number of records returned when a global rule
is searched to 1 (as for other 'search' of push rules in this file).
This bug has been introduced during migration in rev: https://github.com/odoo/odoo/commit/cb486d7eb6353a66eea2cb3610141b4f3a778791
opw-725874
When we are changing the incoming and outgoing routes steps of a
warhouse through its settings, the push/pull rules are actually deleted
and recreated, which raise a traceback if we have some move validated
that are using those rules.
The problem came after rev: https://github.com/odoo/odoo/commit/b1b3de1339a13504ac5e223aec465bd70417d11e
Because we restrict the deletion of rules when they are used in stock
moves.
To fix this issue, we deactivate rules when we change the incoming and
outgouing rules instead of unlink them
It is still possible to have negative and positive quants in the same
location because of returns: if you send something to the customer that
is not there and you return it, you will still be able to reserve the
returned goods to send to another client.
Before, if you would do an inventory adjustment, it would not take into
account these returned quants and their negative counterpart, which made
them difficult to get out of the system.
This fix takes them into account by creating two movements for one
inventory line: move the positive counterpart to the inventory location
before getting back from this location the same quantity.
This way, even if you have 0 as quantity on hand but you have those 2
quants, it will eliminate them. (if you are increasing the stock, part
of the process might have done it automatically already).
Test cases contributed by @jir-odoo
When creating a stock.picking, the related fields picking_type_entire_packs and
picking_type_code were both updated.
This was an issue was required write access on stock.picking.type (warehouse
manager) to create a stock.picking (warehouse user).
The fields were updated as they were present in the view and filled with the
related value. Even if the value was unchanged, it was triggering a write
anyway.
The two fields were in invisible="1" and used only in attrs for other fields.
Making these two fields in readonly does not prevent to use it in the attrs but
avoid to send a value to the server and trigger a useless write.
Fixes#15769
In method `_check_delivery_resupply`, `new_location` is used in a
`write` call. This expects an integer (id).
However, `new_location` is the result of `_get_input_output_locations`,
which returns a recordset.
opw-716141
The total quantity of an inventory only makes sense if the same product is
counted.
This commit avoids useless recompute of the field when a ligne is changed.
The trigger were missing meaning it was recomputed after any change, slowing
down already unefficiant large inventory.
Global push/pull rules are error prone and can be replaced efficiently
by creating a "global" route.
There was an odd behavior when you delete a route, the different rules
of this route were'nt deleted and thus became global. A lot of users
didn't understand that, so to avoid this unexpected behaviour, we
delete on cascade the push and pull rules when a route is deleted.
To avoid inconsistencies in the system, we also restrict the deletion of
rules when they are used in a stock move or in a procurement. We also
restrict the deletion of routes used in warhouses and order lines.
We change the global pull rule test by applying the procurement rule on
a route and apply this route on a product.
Menu items related to global rules are removed, so are the logic to look
for them in the methods looking for which pull/push rule to apply.
joint work by @dpa-odoo, @pimodoo and @sle-odoo
As picking types aren't always used in a picking context, and picking
aren't really meanigful for a lot of people, we rename this concept as
"operation type" in views and in the planner.
When making an inventory adjustment in multi company,
the default location_id was all the time taken from
'stock.warehouse0' even if the user was not allowed to read
the warehouse. Inspired from _get_default_location in pos_config.py
Backport of 8955d15e9d
opw:706704
If the data is available in the current context it should be passed to
_select_seller. The calls to _select_seller throughout the lifetime of a
purchase should be consistent (as possible) or the result of
_select_seller could be inconsistent when dealing with multiple sellers
(product_supplierinfo).
Modify a few signature of private methods to pass available information.
Closes#11414
Before this patch, it was not possible to manually process a pack (i.e.
checking the "is_done" box), because the field was always reset
*before* saving. It was still possible to process it by hitting
"validate", but it was not possible to put a pack in a pack.
Manually process a pack means hitting the checkbox "is_done" on the pack
operation. This "is_done" field is a boolean computed field with a reverse
function, and this reverse function set the "qty_done" on the pack
operation to 1.0.
The compute field doesn't have any depends declared, so the value was
invalidated after any changes in the form view. The computed method was
used to check the checkbox is the "qty_done" is set to 1.0. It was
probably used to check the checkbox when opening later a picking for
which the pack was already processed.
The issue is that the "qty_done" was never updated, because the inverse
method is only called when saving, and the compute method already reset
the "is_done" field to False, as the "qty_done" was not updated.
To fix this issue, we do not use an inverse method but an onchange.
Indeed, this was the expected behavior: hitting the checkbox should
change the "qty_done".
We already have a test covering this use case, committed in v9 [1]. It
didn't discovered this regression because the test was using directly
the "qty_done" field on the pack operation, not the "is_done" field used
in the view. We change the test to use the "is_done" field and manually
trigger the onchanges.
This is due to a bad new API migration [2].
[1] rev e248420348
[2] rev d8548e0771
The search on qty_available was refactored twice:
- b9853db8 to split the method
- a989680b to remove the eval operator
At b9853db8 the order of evaluation introduced a bug so that the domain
('qty_available', '=' 10.0)
was evaluated
if product[qty_available] = 10.0:
which crashed (`=` instead of `==`).
Before b9853db8, this code did not crash as the operator was converted via
if operator == '=':
operator = '=='
which is no longer executed after the split
a989680b replaced the eval by a dictionnary that replaced the eval error by a
KeyError when searching with `=` operator.
This commit changes several things:
- replace the `operator in ('==', '>=', '<=')` as this was evaluated before the
operator replacement code mentionned above
- remove the replacement code as no longer justified since a989680b
- replace the OPERATOR key `==` to always match given key
- Enable lot tracking on Product A
- UoM of Product A is kg, but Purchase UoM is lb(s)
- Create a PO for 200 lb(s) of Product A, confirm
- Go in the picking: 200.01 lb(s) shuold be received according to the
pack operation, while 200.00 lb(s) are expected in the stock move.
The field `product_qty` on the sotck move contains the quantity in kg,
but already rounded from the value in lb(s). If we convert it back to
lb(s), there might obviously be a rounding error, since we do:
lb(s) -> kg -> lb(s)
To solve this, we recompute the quantity in the UoM of the product
without rounding, as a temporary computational value.
opw-705259
xmo-odoo