Earlier, In ERP5Site, we use property 'isIndexable' to have control over indexing and unindexing.
This was usefull specially in case of bootstrap. To have this control, we had a function
`isIndexable` in SQLCatalog which we used to switch for enabling-disabling indexation. (769f9fb2)

Now, we do have ERP5 Catalog, which itself is an ERP5 Object, hence it has an accessor `isIndexable`
of itself which we plan to disable for now(as we don't want circular dependency while indexing
catalog in itself). But as we did have a function `isIndexable` in SQLCatalog which had control
over the indexing, we needed to rename this property for ERP5Site.

Hence, now we use property 'isIndexingRequired' for ERP5Site and use to have overall control
over indexing process.

Please note, we do not intend to change the same property name for any other object. Its just
for ERP5Site.

Also, Update BusinessTemplate installation with updated filter_dict
This removes the need to copy-patch or if-else on meta_type of catalog.
Use dynamic migration while installing the catalog method objects for
bt5.

Note : here we use conversion method for python script but dynamic migration for
ZSQL Methods. This is necessary because after the conversion to erp5 object, we need
to compile the body to generate code object for python script.
By just changing the class, this was not possible.

erp5_catalog: Simplify bt5 installation

/reviewed-on nexedi/erp5!314

This adds a new portal type category, "login", and corresponding
getPortalLoginTypeList portal-level getter.

Now that a user can have multiple logins, create_user_action becomes
always available.

We could go further by changing the API to not cast the result into tuples.

Now ERP5Site_reindex is not called during test setup, thus some tools
added before portal_activities should be reindexed explicitly.

When a user is already authenticated (by any method) and an Unauthorized error occurs, ZPublisher returns the WWW-Authenticate HTTP header which leads to a blocking popup authentication window in user browser.

This patch just desactivate the HTTP header. Except this, error is handled as previously.

ERP5Site.log and Base.log are wrappers to the 'log' function from
Product.ERP5Type.Log, but parameters were forwarded in a wrong way
when called with a single argument:

  self.log(message) # Base method

This was equivalent to:

  log(message, '')  # function from Product.ERP5Type.Log

And the whole message was later part of subsystem in:

  logger = logging.getLogger(subsystem)

But because loggers are never freed, it is important that 'subsystem' does not
vary too often, to avoid a memory leak.

The fix is to simply forwarding parameters with catchall arguments, instead of
duplicating the signature from Product.ERP5Type.Log.

Of course, it remains important to call these methods correctly, otherwise
memory leaks can happen again. For this reason, catchall arguments also
prevents ERP5Site.log and Base.log to be called by ZPublisher.
Reported-by: Kirill Smelkov <kirr@nexedi.com>
Reviewed-by: Kirill Smelkov <kirr@nexedi.com>

Add support for visibility checking.
Use portal_type accessors, not properties.
Also, original implementation of getDefaultModuleId would get the object,
then its id. getDefaultModuleValue using it, it was getting the object,
then its id, then the object again...
Also, follow naming convention: getters returning documents are named
getXxxValue, not getXxx.

The action to recreate activity tables while preserving existing messages
was unsafe for 2 reasons:
- if any error happened, messages could be lost
- it relied on Message.reactivate

Which this patch, any instance created after commit d881edd1 (Aug 2010) will
upgrade successfully. For older instances, make sure you have no activity left.

For cases where 'ALTER TABLE' would not work, a better way to implement repair
functionality would be:
- one action to backup all messages in ZODB
- and another to restore them
And maybe a security so that during the backup-clear-restore sequence,
activities can't be created nor processed.

If any column is added in the future, it would still be possible to write code
that fills them by inspecting messages.

MRP was broken and unused for a long time, since legacy simulation was dropped.
This commits resuscitates MRP, at least:
- expanding, for both operation and sourcing
- building of production reports & production packing lists

Business Processes replaces Supply Chains.
trade_phase replaces industrial_phase
industrial_phase is now used to variate partially produced resources.

Calendar Assignments are now handled in a separate module, update
code in consequence

other ZEO clients even if ZODB Components are not.

Steps to reproduce:

  1/ On zope1, view and edit a person to make sure class is fully loaded.
  2/ On zope2 add an interaction in person_interaction_workflow and add a script raising an exception.
  3/ Edit a person on zope2. The exception is raised, confirming that the interaction is called.

  When editing a person on zope1, the exception is not raised.

ZODB Components: No need to migrate Component Tool, only exist since Portal Type as Classes and ZODB Property Sheets.

Because of recently added Component Tool, POSKeyError exception was raised
when trying to load it from ZODB during migration of Portal Type classes and
ZODB Property Sheets (PickleUpdater() in ERP5Site.migrateToPortalTypeClass),
so make sure that there is a commit before loading anything from ZODB.

Before, it was in Site _local_properties, but as this is stored in ZODB, old
sites would not have this property and would thus not allow to modify it
through 'Properties' Site tab.

When starting a node, ERP5Site.__of__ calls ComponentTool.reset(), which was
never synchronised so it returned True (without generating a new cookie at its
level) and causing synchronizeDynamicModules to be called with
force=True. This generated a new cookie and leading to dynamic classes being
meaninglessly regenerated on all nodes.

Instead, modify ComponentTool.reset() behavior so it *always* reset Portal
Type classes when Components are reset (as it should have always been as the
class inheritance may have been modified) and force regeneration of Portal
Type classes in this method if reset is True.
Signed-off-by: Vincent Pelletier <vincent@nexedi.com>

This reverts commit 6fc11699.
Some test fails, please review

Since erp5_xhtml_style has become requiring erp5_jquery. (in reality required since 2010)