The check was means as an optimization: no need to fetch at tray already
open. But "fetch_tray" will not only open the tray, it may also move the
laser on the exact position. So we should do it for every inventory line.
* 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.
* Rename methods that fetch a tray to prevent confusion
* Add methods to release a tray
* The Kardex method to fetch a tray has to send "0" in the carrier and
carrierNext field
* The pick and inventory screens release the tray only when there is no next
line, because the release is implicit when we fetch the next line,
the put screen releases everytime because the operator may take time
to start the next line and we don't know if they are going to scan a
next line or not.
* Exiting the screen or switching screen between put/pick/put-away has
to release the tray as well.
When the shuttle screen propose a tray based on a tray type and we
are in the 'save' step, where we are supposed to physically putaway
the good and save, we should still be able to change the tray type
to fetch another tray.
Compatibility module between stock_vertical_lift and stock_storage_type
(in OCA/wms).
In the vertical lift's Putaway screen, when a good is scanned for a putaway, the
user has to scan the tray type of the corresponding size, so an empty place in a
matching tray is found. When we use storage types, we should know what tray is
compatible with the storage type.
Changes with this module:
* The storage types of trays cannot be selected in the locations form, they have
to be set in the Tray types.
* In the lift put-away screen, when a package has a storage type, the user isn't
asked to scan a tray type, instead, the putaway of the Package Storage Type is
applied.
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.
* The change of destination location was not updated on the screen when
the barcode was scanned (it was when the "manual barcode wizard" is
used though)
* We should be able to pick partially available move lines
* prevent to scan a location when no move line is selected or the move
line has already been set to done
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.
There is no such action as 'ir.actions.do_nothing', it kinda works,
until you look into the js console and stares at the errors.
There is a nice OCA module that serves this purpose (more or less,
because it reloads the window, this is not an issue).
When we refresh the page on the browser when we are using the "screen"
view, odoo loses the information that we want the view to be headless,
fullscreen, etc. so it's displayed pretty badly. This view is a
work-around: its priority is lower, so it will be picked up by default
on loading, and a button allows to re-open the screen view with the
proper options.
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.
* Add vertical_lift_shuttle_id field on stock.location, help to find the
shuttle for a location
* Add StockLocation.fetch_vertical_lift_tray(), that needs to be
implemented in addons to send commands to the hardward to fetch a tray,
and if existing show a cell (laser pointer, ...)
* Add helpers on stock.move.line fetch_vertical_lift_tray_source() and
fetch_vertical_lift_tray_dest() that fetch the tray directly from a move
line's source or destination location
