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.
* stock_vertical_lift: make pkg compute more solid
Somehow sometimes you can get a move line without product
while computing product packaging in inventory.
Make it more defensive and skip packaging rendering if no product is
there.
As the template is not used by JS we can pass full objects to it.
This way we can use any recordset information directly in the template
without having to override the method.
Instead of going through the onchange machinery.
The intended usage of onchange methods is to update something on the
screen, without side-effects in the database, then let the user save
the form with the proposed changes.
Weirdly, the barcode scanner event triggers an onchange on the field
`_barcode_scanned`.
It doesn't work well with our use case, as the whole form is read-only
and we only care about having the barcode events doing side-effects on
the backend and displaying back the changes.
This particular onchange will then be executed as a normal method, with
side-effects. However, contrarily to other actions on the form, the
frontend does not reload the view after an onchange, as it relies on the
data returned back in the values. As we cannot know which values may
have been changed in the different implementations (location
destination, state, ...), the onchange returns a read with every field.
Example of usage in an odoo shell, when a screen is open:
>>> self.env['vertical.lift.shuttle'].browse(1)._operation_for_mode().operation_descr = 'foo'
>>> self.env['vertical.lift.shuttle'].browse(1)._send_notification_refresh()
>>> env.cr.commit()
Provided the longpolling is correctly configured with a proxy, the
screen should immediately refresh with 'foo' as operation description.
Namely, the pick/put/inventory operations are now split in
different models.
Pick and Put share a model and customize their behavior, which is pretty
similar. The inventory operation will have a different view and
different workflow.
This changes will ease a lot the customization of the different
workflows and views.
