because __str__() returns id in Zope2 but returns login in Zope4.

  Allow the developer associate a Mixin on Business template level
without require to overwrite the portal type itself

  Include mixins can be done in the same way, allowed content types or
property sheets are set.

erp5_administration: Add Scripts for Alarm to update validation state according to consistency state

    If two open orders are validated on the same transaction, archivePrevious script will get the an already archived as catalog will be outdated.

   This is an alternetive way to login using Certificates. Probably this format
   will evolve into use caucase;  however this only introduce some most basic features.

   Use Certificate Login for store login definitions

  Please squash me in future.

  If the user wants actitivites, it should create multiples StandardBT5ConfiguratorItems,
  This should accellerate Tests based on ERP5Configurator.

  This should be recoded, but it should speed up bootstrap of a site,
  as get modified objects are not called.

It the user don't have fully permission on the object (already changed state), this set will fail to check if source should be defined.

  The upgrade ordering seems buggy and requires to force reinstall it

This allow during a subscription process, create a user and them create all
documents using that user w/o rely on proxy roles (keeping good ownership
across the documents).

Without this (on slapos master ui) the redirection places value unquoted causing parser to fail later on when resolve {n.me}

  The user can be present from diferent logins, password tool only works with ERP5LoginUserMager
  users.

Returning true allows to add movements to existing one, and this group shall
always separate them.

XMLExportImport encode strings in base64 when they can not safely be
represented in XML (including for exemple "\n"), so we can not use
this information to decide if this a BINBYTES or a BINSTRING pickle
opcode.

For now, it's still unclear how bytes and str should be handled, so
while using python2 it's better to keep using str everywhere and not
introduce zodbpickle.binary that looks like str on python2 but will
become bytes on python3 and have consistent data everywhere (ie.
everything str)

BINBYTES is not fully removed from the patch, because we'll want to
use it later, but it is in "if" that is always false.

This reverts commit c45c2295.

to get test passing again

On Zope4 these settings are no longer in zope.conf

We now target transaction 3 so this patch is not longer compatible and
no longer needed according to discussions on the launchpad issue.

_sort_key is also set to '1' on recent Products.ZSQLMethods

For now, remove it completely. If necessary `registerHelp()` can be used.

  commit f3ab4409bfa9a3e1943099c8ae391a2f0273b53b
  Date:   Sat Jul 2 18:26:53 2011 +0000
    Removed the old help system, in favor of the current Sphinx documentation
    hosted at http://docs.zope.org/zope2/. For backwards compatibility the
    `registerHelp` and `registerHelpTitle` methods are still available on the
    ProductContext used during the `initialize` function.

Unlike StringIO.StringIO().tell() and open().tell(), which all return
int, io.BytesIO().tell() returns long. Because io.BytesIO is used when
uploading files on Zope4, this cause PropertySheetValidity errors when
checking consistency, because Data.size property is expected to be int.

Checks that created document types match constraints

Previously, we were using an encoded string, which in practice worked,
but with python3, WSGI server will encode as latin1 (because WSGI is
latin1) and already with Zope4 on python2 we have issues with testing,
as functional testing fake WSGI server only accepts ascii headers [1]

1: https://github.com/zopefoundation/Zope/blob/cddecf7e/src/Testing/ZopeTestCase/functional.py#L125-L126

Since Zope 4, the `standard_error_message` is rendered in the context
of REQUEST['PUBLISHED'], which in case of publishing a skin (page
template or script) in the context of a document is is the skin itself,
but for error rendering in case of erp5_web Web Site or Web Section,
we expect standard_error_message_template to always be rendered in the
context of the document, that's why we use REQUEST.PARENTS[0] as context.

REQUEST.PUBLISHED = <PythonScript at /erp5/script used for /erp5/module/document>
REQUEST.PARENTS [<Document>, <Module>, <ERP5Site>, ...]

No longer needed on Zope4, from commit dc5b9292f (Merge pull request
 387 from zopefoundation/re-379-revert-repr, 2018-10-26)