GitLab

This reverts the following part of 5d9c30e:

* Upon bt5 installation, install portal_type* items before bt5 {Document,
  Extensions...} as corresponding Portal Type are required once they have been
  migrated to ZODB Components.

This obviously does not work as the Document can be used as Type Class and
also because tool_item is required before portal_types for example (see
test_type_provider).

When bootstrapping erp5_core and installing for example an Extension
Component, this will try to load Extension Component Portal Type which does
not exist yet but fallback on its document class instead, which is enough
until Extension Component Portal Type is installed.

* Upon bt5 installation, install portal_type* items before bt5 {Document,
  Extensions...} as corresponding Portal Type are required once they have been
  migrated to ZODB Components.

* Likewise portal_{property_sheets, types}, portal_components must be created
  automatically *before* installing any bt5. This is required when Products
  will be migrated but also for bt5 items before bootstrapping erp5_core bt5.

* Set Permissions in ComponentTool instanciation and revoke all permissions,
  then allow only some of them for security sake.

* When creating ERP5 site with unit tests, add ERP5TypeTestCase to Developer
  Role ASAP so that there is no Permission issue when installing bootstrap bt5
  and test bt5s containing ZODB Components.

Also, upon installation of bt5s, install WorkflowItem before Components as it
is needed to restore history.

Another solution would have been to validate() ZODB Components automatically
upon bt5 installation but it would mean losing 'modified' state information
and also imply that *all of them* will be validated even if a developer wants
to publish non-validated ZODB Components.

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: Vincent Pelletier <vincent@nexedi.com>

Upon Business Path Item installation, update Local Roles of objects whose Portal Types defines Roles.

Before, Local Roles were not updated upon Path Item installation, thus leading
to security issues (such as Trade Model Line). This avoids ugly hacks in
Upgrader and in tests as well.

Also, move Portal Types Role installation before Path so that they can be used
before updating Roles during Path installation.

If an user has set SVN working copies in its preferences, it cannot be
modified anymore after upgrade.

We were not able to export and import back roles of a document when more than
one local role group id was used.

Although this also fixes "too many files" error, the way to upgrade some kinds
of objects should be reviewed in order to avoid such export/import.

Add back wrongly removed volatile conversion caching.
Use new set / get Cache bag API.

In products/ERP5/Document/BusinessTemplate.py, when trying to build
an item, an error occured because item was set to None by clean method.

Remove not used proeprty.

While installing a BT5 make sure not to install duplicate keys for the following ZSQLCatalog properties:
 - sql_catalog_search_keys
 - sql_catalog_related_keys
 - sql_catalog_scriptable_keys
 - sql_catalog_role_keys
 - sql_catalog_local_role_keys

Remove code duplication and make it easy to override how the key should be modified at install time.

way it's exported / imported and tested.

Try to support migration of old instances (containing old erp5_property_sheets)
with recent products. This is especially visible with BusinessTemplate property sheet
when new filesystem versions require an up to date erp5_property_sheets bt5 which itself
can not be installed.

erp5_property_sheets has not been upgraded yet.

This is similar to portal skins priority, except that versions and priorities
are defined on ERP5Site (as 'VERSION | PRIORITY' where PRIORITY is a float) as
there is not one Folder for each version in contrary to portal skins.

On the Business Template itself, versions and priorities can be defined like
'VERSION | PRIORITY' or simply 'VERSION' (where PRIORITY is assumed to be
0.0). Upon installation, it will be merged into ERP5Site property in
descending order (by priority first and then by version for versions with the
same priority).

Only consider .py and .xml files when importing BusinessTemplate files in FilesystemToZodbTemplateItem.

This fixes tests failures with ``AttributeError: 'str' object has no attribute
'text_content''' due to .pyc files.

This fixes filesystem Document-related tests in testBusinessTemplate.

The only purpose of having Interaction Workflow defined on ComponentTool
_setObject and _delObject was for BusinessTemplate installation and
uninstallation, however the reset was also triggered when a new draft
Component was being added. Instead, perform the reset in BusinessTemplate
DocumentTemplateItem.

Also, Rename *MigrateAllComponentFromFilesystem to *MigrateSourceCodeFromFilesystem.

Instead, use savepoint which avoids triggering interaction workflows.

Also, set _archive properly for ZODB Document and Extension.

This reverts commit deb7e37e7690d50a6dc1e9aab05f4a7099973287 which introduced
a regression (test_BusinessTemplateWithDocumentPropertySheetMigrated failed).

Conflicts:

	product/ERP5/Document/BusinessTemplate.py

Add Business Template action to import Document and Extensions automatically after giving the version.

Migration is now performed at Business Template level as it makes more
sense rather than on Component Tool which would require specifying the
target Business Template to update Document Template Item and
Extension Template Item.

When versions will be introduced, there will be an import action which will
take the required version. Moreover, there are not so many Extensions and
Documents to migrate after all and Products will have to be migrated manually
as well.