When checking constraints, ignore lines where the node is an acquired
organisation, we should only consider lines where node is an account.

(cherry picked from commit c61cde5b)

Because we often want to manage those through simulation.

For consistency with all other default builders

generally speaking, listbox where some editable fields are not listed in fields
(cherry picked from commit 9abfc6c4)

(cherry picked from commit 2b084cbd)

A supply line defined for a product line will apply to all resources
member of this product line.

(cherry picked from commit 3751610a)
Conflicts:
	bt5/erp5_pdm/SkinTemplateItem/portal_skins/erp5_pdm/PurchaseSupplyLine_view.xml

(cherry picked from commit 0ad99c2d)
Conflicts:
	product/ERP5/tests/testTradeCondition.py

A previous operation might have poluted the request
(cherry picked from commit 7ddb9c10)

index

we have a scriptable key for title_or_reference :
from Products.ZSQLCatalog.SQLCatalog import Query, ComplexQuery

query = ComplexQuery(
  Query(title=value),
  Query(reference=value),
  operator="OR")
return query

Otherwise we quickly end up with thousands of activities when one builder has a problem.

(cherry picked from commit 83df786f)

and fix a typo

(cherry picked from commit 1bd9309a)

(cherry picked from commit 3d7289b9)

Also, add Javascript and CSS linters.

(cherry picked from commit 1d4a9b67)

Add "planned" state to Purchase/Sale Packing Lists so that builders first build planned deliveries.
Then if there is no expected additional movement, the delivery is automatically moved to "confirmed".
This allows to support partial build that could come with global builders. Now builders will complete
only "planned" deliveries. This also solve the split of packing list when the same date was used,
the builder was updating current delivery. Now we can change packing list only in confirmed state
(not in planned state), therefore the builder will never add movement to the delivery the user is
changing.

This was adapted from seb commit to project repo. The difference is that here we do not confirm if
related movements belong to more then one root delivery value (packing list). This way we try to
handle the case of multiple split on the same date where the user first splits a packing list and
then splits again. In this case we want these splitted movements end up in the same packing list,
so the created packing list still has to be able to receive new movements, it is thus kept in
planned state. The user then hast to confirm this packing list manually.

Conflicts:
	bt5/erp5_pdm/SkinTemplateItem/portal_skins/erp5_pdm/Base_viewPDMFieldLibrary.xml

- Optionally group by function
- Give higher priority to Order Report compared to Workflow Report
- Optionally filter by Quantity Unit and enable Stat Columns for Quantity

TODO: Quantity also for Thirs Party if filtered by quantity Unit

Temporarly Revert "stop copying (deprecated) Payment Condition documents from Trade Condition to Order, and from Order to Packing List."

This reverts commit eb5fdbe3.

Conflicts:
	bt5/erp5_trade/bt/revision
	product/ERP5/tests/testTradeCondition.py

And merged with 5c09e2e2

directly use portal_catalog on select methods instead, see
commit 5a0b9189