Several changes were done because of the code review:
* The category of the module is now "Warehouse", in alignment
with the categories user in OCA (https://odoo-community.org/shop)
* The list of fields in the depends() for the method
_compute_last_inventory_date() missed several fields, that are
now listed as dependencies.
* A new unit test has been added to account for the concern of the
functional needing a compute_sudo in its definition, just in case
a non privileged stock user was stuck into permission problems.
This new module adds a stored computed field on locations that stores
the last inventory date for the location, for validated inventories.
This is only computed for leaf locations, not parent ones.
In the screen for the vertical lift shuttles, accessible through
Inventory > Operations > Vertical Lift Shuttles, a new button has been
added to allow to skip an operation. This button can also be triggered
by scanning the barcode O-BTN.skip.svg that is inside the folder
'images'.
When a skip is done, the next stock.move.line to pick is chosen and
shown to the operator. A skipped move line is added to the end of the
list of pending move lines to be picked, so they will be shown again
in the future as soon as the other move lines have been successfully
processed.
This option was added because, sometimes, the operator can not process
a move line for whatever reason. Right now, the only way of proceeding
is to wait until he/she can effectively process it, which involves a
delay in the operations. With this new skip operation, the operator
can continue processing the rest of move lines.
* Any child_ids changed on a children_ids should recompute locations:
otherwise only 2 levels are updated.
* Flush any change in the hierarchy before executing the SQL
The test creates 2 product.product on the same product.template,
which is illegal if they don't have different attribute values.
No error is raised, unless another modules runs a "flush", which
does the INSERT in database and fails with:
psycopg2.IntegrityError: duplicate key value violates unique constraint "product_product_combination_unique"
DETAIL: Key (product_tmpl_id, combination_indices)=(31, ) already exists.
The former implementation was to take as much as possible of the largest
packaging, to the smallest packacking, to have less to move.
Then, only, removal order (fifo, ...) was applied for equal quantities.
It is more important to respect removal order than limiting the
operations, so remove this "optimization".
The former implementation was sorting the quants per location and trying
to take as much quantities as possible from the same locations, to limit
the number of operations to do. Then, only, removal order (fifo, ...)
was applied. It is more important to respect removal order than limiting
the operations, so remove this "optimization".
If there is two move lines for the same product in the vertical lift
(stored in2 differents trays for instance), the pick scenario was
failing when the user was processing the first line.
To circumvent this, instead of validating directly the move, we put the line
in its own stock move, then we put the stock move in its own transfer and
validate this one.
Methods used to do that have been copied from the `shopfloor` module,
they probably deserves their own module as they are quite generic.
