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

erp5_trade: 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

1. upgrade epos-print
2: print with html5 canvas to support chinese characters

(cherry picked from commit eed6ff24799a73a63327152a662669ba3ecfc391)

Added aggregate item and item creations actions on new portal types.

(cherry picked from commit a32a565f2e4921c087803aa526bca8c853e18887)

Conflicts:
	bt5/erp5_item/bt/revision

 Introduce temp_object parameter on builder.build() and propagate it
 over until the newContent() calls. This change allow use create
 Temporary Documents intestead real ones, like a "preview".

(cherry picked from commit 959776ce50c2e7ee2b8f9945ec91a2e0fbe08619)

Conflicts:
	product/ERP5/Document/SimulatedDeliveryBuilder.py

Since 264ded5c in ERP5JS we render the form directly after a successful edit, but this was done sometimes too early, namely, the next form was rendered before interaction workflows and this leads to problems like the ones discussed in nexedi/erp5!982 (comment 92893)

/reviewed-on nexedi/erp5!1040

This test click on the delete button which deletes by an ajax request
and immediatly after open the "wait for activities" page. Sometimes the
second request starts before the first is committed, so there are no
activities to wait for.

When using ZServer, we had only one worker thread, so this was not
visible, but with wsgi we have more than one so it happened sometimes.

Use an old jQuery trick to wait that the first request is no longer in
flight.

/reviewed-on nexedi/erp5!1038

Also covers traversal (and a lot more).

https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-02

SameSite=None breaks the compatibility with some browser versions.
https://www.chromium.org/updates/same-site/incompatible-clients

We choose Lax and not Strict so that we can open links to ERP5 from
external applications and so that OAuth Logins work. Implementing the
"two cookies, one for read one for write" approach suggested in
https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-02#section-8.8.2
would be too big change at this point.

Allow instances to surcharge the SameSite value for some specific domains if needed,
by surcharging the ERP5Site_getAuthCookieSameSite script.

We want to render the next page after interaction workflows are
executed.

This uses a foo_interaction_workflow that sets a short title when title
is set to a special value. We use it to check that when user set the
title to that special value and save, next time the form is displayed,
the values displayed are the ones after interaction workflow modified.

This is a simple and a bit unrealistic scenario, but we have for example
interaction workflows that update security definitions when some
properties are modified, we want the next form to display the values
after modifications.

This is also the case of editions of portal components which sets the
document to "modified" state and "re-validate" it at the end of
transaction, unless pylint detects error.

action added in a previous commit was removed, probably by mistake
because only the metadata was removed.

workflows were not sorted and some metadata files have an extra \n,
probably because of manual edit

This uses a different approach that what I was using in the past. I'm no longer trying to rename skins that does not match our naming conventions, but just adding them the the "ignore list".

This would still allow to detect when new wrongly named scripts are introduced without risking regressions when we rename a script that was used from some places we did not change (like project customisations).

/reviewed-on nexedi/erp5!1041