product.template, now takes in account variants and correctly displays value.
[FLAKE8]
Removing duplicate modules and moving README.rst into __unported__
Generic module to compute the stock quantity available to promise using several implementations.
stock_available_immediatly is changed to become the first optional implementation.
Cherry pick of commit 0b060f619f from the v7 branch
[IMP] stock_available* uses new API
[IMP] READMEs and TODOs
Cherry-picked from v7 at 8add4bea7e
Conflicts:
__unported__/stock_available_mrp/__openerp__.py
stock_available/__openerp__.py
stock_available_immediately/__openerp__.py
[UPG] Upgraded to version 8, fixed references to new 8.0 views and moved fields that were in product.product to product.template
[fix] remove duplicate view and correct view name
[UPG][FIX] added outgoing field XML, that was in the base stock field in 7.0.
[UPG] stock available immediately, corrected the calculation method of
immediately_usable_qty to take in accountthe sign change in outgoing_qty
(from negative to positive) in version 8.
[FLAKE8]
[FIX] renaming of a class, comment removing, useless code.
[UPD] move out from unported to 8 for update
[fix] remove duplicate view and correct view name
[UPG][FIX] added outgoing field XML, that was in the base stock field in 7.0.
[FIX] renaming of a class, comment removing, useless code.
[fix] remove duplicate view and correct view name
[UPG][FIX] added outgoing field XML, that was in the base stock field in 7.0.
[UPD] move out from unported to 8 for update
[fix] remove duplicate view and correct view name
[UPG][FIX] added outgoing field XML, that was in the base stock field in 7.0.
[FIX] renaming of a class, comment removing, useless code.
[UPD] move out from unported to 8 for update
[fix] remove duplicate view and correct view name
[UPG][FIX] added outgoing field XML, that was in the base stock field in 7.0.
[FIX] renaming of a class, comment removing, useless code.
[UPD] move out from unported to 8 for update
[fix] remove duplicate view and correct view name
[UPG][FIX] added outgoing field XML, that was in the base stock field in 7.0.
[FIX] renaming of a class, comment removing, useless code.
[fix] remove duplicate view and correct view name
[UPG][FIX] added outgoing field XML, that was in the base stock field in 7.0.
[UPD] move out from unported to 8 for update
[fix] remove duplicate view and correct view name
[UPG][FIX] added outgoing field XML, that was in the base stock field in 7.0.
[FIX] renaming of a class, comment removing, useless code.
The first method is: StockLocation.is_sublocation_of()
This method is currently used in:
* wms/stock_dynamic_routing
* wms/shopfloor
* wms/stock_move_source_relocate
* stock-logistics-warehouse/stock_reserve_rule
* ddmrp/ddmrp
The goal will be to use this module as dependency instead of
reimplementing the method in each.
Other methods should follow in "stock_helper".
Note: I opened https://github.com/odoo/odoo/pull/53866 to propose a
generic version of this method, expecting odoo's opinion, but got no
answer.
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.
When the 2 last moves of a stock.picking are assigned at the same
time by 2 jobs (different products both available), none of the
transaction will see that it is the last move to be assigned. As a
result, the picking will stay in state "confirmed" even if all its
moves are assigned.
Lock the stock.picking records when we call auto_assign.
If we have many pickings touched for the same product, the lock
can be quite large, so we may have to find a better option.
I could not write a test to exercise this, because we can't have 2
transactions being aware of it, even if we create the picking in demo
data as tests can be run during install.
