This reverts commit 35b2c024.

Allow edition in the new UI

This reverts commit 66f30ebb.

Revert "ZODB Components: Non-core bt5 with 'Document Component' overriding standard ERP5 Document must create its own version_priority."

This reverts commit ee686cac.

Revert "ZODB Components: When migrating FS Mixin, set the ZODB Component reference to the class name (like Interfaces)."

This reverts commit 2b8c6305.

This reverts commit 937500a1.

Revert "ZODB Components: Resetting Portal Type classes was also clearing Interfaces of erp5.component.* modules."

This reverts commit f1f415a3.

This make everything slow as hell and prevent to quickly save.

- use global preference to get publication section value
- test updated

/reviewed-on nexedi/erp5!1017

ZODB Components: Resetting Portal Type classes was also clearing Interfaces of erp5.component.* modules.

__implemented__ and __provides__ attributes are cleared on Portal Type reset
to break a circular reference (11e2b506). Resetting of ZODB Components is
done independently of Portal Type classes, so until the next ZODB Component
reset, Interfaces were not implemented anymore.

11e2b506 states that this creates a memory leak but this is not actually true
as Python garbage collector will break such circular reference and collect
this object, as asserted by a newly introduced Unit Test. This is probably
less efficient than explicitly breaking the circular reference and thus relies
on reference counting (rather than the garbage collector) but doing otherwise
would require introspecting ZODB Components module to find classes implementing
Interfaces (erp5.portal_type only contains classes).

This only takes care of ZODB Components modules but maybe breaking circular
references for Portal Type classes is not even needed (if so, this will be done
in a later commit).

ZODB Components: When migrating FS Mixin, set the ZODB Component reference to the class name (like Interfaces).

ZODB Components: Non-core bt5 with 'Document Component' overriding standard ERP5 Document must create its own version_priority.

Otherwise this will clash when standard ERP5 Document will be migrated to ZODB
Components to erp5_base.

Like Document and Interface Components for the same reasons (694c9fee).

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.