(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

This was a false positive

We should be able to configure a group calendar saying that the pattern
is "from 9:00 to 12:00, repeat every monday morning" with a group
calendar assignment saying "use this pattern from 01/01/2016 until
31/12/2016" and then create another group calendar assignment for 2017
without having to change the periodicity stop date on all presence
periods of the group calendar.

I think it should repeat from group calendar assignment's start date
until min(group calendar assignment's stop date, presence period's
periodicity stop date).


/reviewed-on nexedi/erp5!125

/reviewed-on nexedi/erp5!940

 - update PresencePeriod.getNextPeriodicalDate with fixes from 6155f7ff
 - do not use addToDate, but simply DateTime arithmetics that unlike addToDate, works correctly