Record rules used to not be checked on stock quants, but now they are since Odoo's commit 2fd14db57433d08ab368a7e18d18ae8d49dafab1 (https://github.com/odoo/odoo/commit/2fd14db).
In our test we changed the company of the products and BoMs but we neglected that the stock was not attached to the right company, and that made the test fail.
To fix that, make the test inventory for the right company.
Since there is a little inconsistency in the demo data with a negative quantity of an unrelated product, use the `partial` filter for the inventories instead of the `none` filter, so that no wrong inventory lines are added automatically.
sudo is not required since mrp.bom are readable to groups with access to the qty_x fields on a product. Moreover using sudo to retrive the bom will ignore the company_id defined on the bom
Compute potential quantities for both product templates and variants. To keep the code simple, only the biggest potential of any single variant is accounted for in the template's potential.
Take all levels of phantom BoM into account, respects validity dates etc. thanks to the use of the standard method _bom_explode, as suggested by @gdgellatly in https://github.com/OCA/stock-logistics-warehouse/pull/5#issuecomment-66902191
Improve tests, rewritten in python.
Adhere to new file/manifest/README conventions.
Simplify copyright headers
There are cases where we dot NOT want to simply sum the quantities of all the
variants. For example when dealing with manufacturing capacities, we may have
to chose between variants because we can't make ALL of them with the same
components.
So instead of a simple non-modular implementation, we'll let each module define
his own implementation of how to compute the product template's quantity
available for sale.
Conflicts:
stock_available/__openerp__.py
stock_available_immediately/__openerp__.py
As explained by Raphaël Valyi in https://github.com/OCA/stock-logistics-warehouse/pull/94#discussion_r45978223 :
Some may need to override this domain. Example: in Brazil we will probably separate quants of the same product depending on if it comes from national origin or if it's imported. It's the same product in the MRP for instance. But for fiscal reports we cannot mix quants and we don't want to freak with lots for product origin. In this case we would need to override this domain, but may be there are other use cases.
