It does not have any impact in current stable as the inherited
method does not use it. However if another addon inherit it
it will not receive access_token depending on call chain. Let
us fix it.
When you change the quantity done of a done move of a product valuated
by standard price in perpetual valuation, the price used to update
create the corrective journal entry is the price unit of the move
instead of the standard price.
This behaviour leads to iconsistancy like having a empty stock and still
have a valuation on the stock valuation account.
To fix this issue, we check if we are working in standard price and use
the standard price of the product instead of the move unit price.
- Invisible 'Shipping Policy' and 'Priority' for Reception.
- Invisible Operation Type when it's in the context.
- Changed shipping policy 'Partial' to 'As soon as possible' and 'All at once' to 'When all products are ready'.
- Added stat button in stock_quant for open stock_move_line.
- Added 'Reserved Quantity' field.
- Moved UoM on right of 'On Hand'.
- Set product name in breadcrumb instead of 'stock.quant,2'
- Added new field 'reserved_quantity'.
- Added new filter Reservations('reserved_quantity').
- Removed 'Transit Location' default filter and keep only 'Internal Location'.
- Added graph view in stock quant.
- Added Product Template in search view.
- Removed class on origin field for display full width.
- Moved uom on the right in move lines internal tree view.
- Moved Cancel button on the right in header of do form view.
- Renamed menu 'Stock Moves' to 'Picking Moves'
- Renamed menu 'Stock Move Lines' to 'Product Moves'
- Added default filter 'Done' on Stock move lines.
- Moved date field at the first.
- Removed groups to visible Source and Destination Location id multi-location is not activated.
- Set groups on location menu for visible only if mulit-location is set.
- Restrucured the menus in configuration.
- Products
- Categories
- Barcode Nomenclatures
- Unit of Measures
- UoM Categories
- UoM
Make sure '.o_invisible_modifier' table-cells are forced back to
`display: table-cell` to keep correct alignement. Indeed using the
`initial` value forced them to `inline` instead (creating some
obvious visual bugs in some cases).
The problem occurred on form views with an x2many field with a
default value containing CREATE commands, i.e. when opening such
a form view in create mode, the x2many field is pre-filled with
some (non-existing yet) subrecords.
If the user then edited those subrecords, and then clicked on
'Save' to create the main record, an 'UPDATE' command was sent
alongside the 'CREATE' one for the x2many, and the id of the
'UPDATE' command was a virtual id (as the subrecord didn't exist
yet), and it crashed.
This could happen in MRP:
- Enable lots in Iventory
- Choose a product which is a component of another (through mrp bom)
- Set this product as tracked by lot
- Set this product inventory quantity to 0
- Create a new manufacturing order for the product for which it is a
component
- Click on "Check Availability"
- click on Produce: the many2many already contains a subrecord
- edit the lot field of that subrecord
- click on 'Record Production'
When updating the quantity to produce on a MO, the quantity done
on finished/consumed moves that were not done was erased.
It happens due to write on stock move that always wanted to
unreserve the move and thus drop the move lines with qty_done.
This issue has been resolve in previous commit
This commit correct some mistakes in wizard methods in order
to correctly update open moves.
Write method on stock move always unreserve concerning move if
initial demand is modified. Unreserve will delete all move lines
linked to the move including those already modified.
Thus modify initial demand(unreserve) will destroy all the
job done by the user.
This commit will only unreserve move is the initial demand
is smaller than the quantity reserved (could be improved by dropping
only few move lines). If the initial demand is greater than the
reserved quantity it will not unreserve but only change the
state to partially avaialbe.
When the external button of a many2one field is clicked, the
related record is opened in a dialog. When the user clicks on
'Save' in this dialog, a 'reload' event is triggered to reload the
parent view (the one in the background), as the display name might
have changed.
However, when there is another many2one field in the opened dialog,
and if its external button is clicked, there are 2 opened dialogs,
and thus 3 nested form views. If the user clicks on 'Save' in the
third one, only the direct parent view must be reloaded (the one
in the first dialog).
Before this rev., the 'reload' event wasn't stopPropagated, so it
was handled by the view in the dialog, and by the one in the
background, which produced a crash.
This could happen for instance in Sales Order, edit a sale order
line, click on the external button of the product, in the dialog,
click on the external button of the category, edit some field and
click on 'Save'.
Closes#19052
Before this rev., when the user pressed 'TAB' in the last cell of
the last row of an editable list with attribute create="0", a new
line was added to the list, thus totally ignoring the attribute.
Now, it goes back to the first cell of the first row instead, as it
was before the new views.
Closes#19053
Thibault Delavallée