Just use erp5_default_business_process as specialise so that expand does
not fail and we can still have item management tested until test suite
is fully updated for new simulation.

More complex tests that deals with divergence are left as
newSimulationExpectedFailure for now.

This reverts commit 0168bf60

/reviewed-on nexedi/erp5!69

where the actual Python code or Test content is exported separately from the xml metadata

to use content_type or reference even if the object is broken.

to the Portal Types for which the data
is exported separately to the meta-data.
Tests added to testBusinessTemplateTwoFileExport.py

testTemplateTool.test_revision: Change hard-coded hashes. test_core file structure has changed since SkinTemplateItem/portal_skins/erp5_test/test_file has been separated to two files

All business templates migrated to new format with files like Python Scripts, Web Pages, Web Scripts etc. separate to xml

erp5_web_renderjs: Set init script for Web Script and Web Style so that it sets content_type as 'text/javascript' and 'text/css' respectively

erp5_core: TemplateTool: Add a view in import/export dialog, so that migration to new format can be automatic

TemplateTool: importAndReExportBusinessTemplatesFromPath renamed to importAndReExportBusinessTemplateListFromPath

BusinessTemplates: Allow export of files like Python Script, Web Page, Web Script etc. separately from the xml

MessageTranslationTemplateItem: fix in _import so that the path of the .po files are the same as in build

BusinessTemplate.py: Class CatalogKeyTemplateItemBase: fix so that in export the items are exported in the correct folder

Fix unit test errors due to data remaining from other tests

Like we already do for Documents, Tests and Extension, we are soon
going to export as two files various types of document. It's usually
one file for metadata, and one file for the content (code, text).

Sometimes, we might want such kind of two file export for some  bt
having portal type and instance of such portal type in the same time.
In such case, we have some intermediate steps where we have broken
objects, and we need to change theses broken objets before portal
type is fully initialized and installed.

Such error was raised :
BrokenModified: Can't change broken objects

We were installing a broken object even though the portal type was just
installed. This was due to a missing reset of components.

Following code, with foo having portal type Foo which is
not installed yet (thus it is broken) :
connection = self.getConnection(portal)
foo = connection.importFile(file_obj) => this does a savepoint
foo._p_changed = 1

Then next savepoint was raising :
PicklingError: Can't pickle <class 'erp5.portal_type.Foo'>: it's not the same object as erp5.portal_type.Foo )

This was because we had :
foo.__class__.mro() : (<class 'erp5.portal_type.Foo'>, <class 'ZODB.broken.PersistentBroken'>,
 <class 'ZODB.broken.Broken'>, <type 'persistent.Persistent'>, <class 'erp5.portal_type.Foo'>,
 <class 'Products.ERP5Type.dynamic.lazy_class.GhostBase'>,
 <class 'Products.ERP5Type.dynamic.lazy_class.ERP5BaseBroken'>, <class 'Products.ERP5Type.Base.Base'>, *TAIL)

and

erp5.portal_type.__getattribute__("Foo").mro() :
(<class 'erp5.portal_type.Foo'>, <class 'Products.ERP5Type.dynamic.lazy_class.ERP5BaseBroken'>,
  <class 'ZODB.broken.Broken'>, <class 'Products.ERP5Type.Base.Base'>, *TAIL)

Classes where different because new class with new inheritance was created by
ZODB.serialize.ObjecReader.load_persistent which does :

if issubclass(klass, Broken):
    # We got a broken class. We might need to make it
    # PersistentBroken
    if not issubclass(klass, broken.PersistentBroken):
        klass = broken.persistentBroken(klass)

Since ERP5BaseBroken is patched to mostly be like a PersistentBroken,
make sure we allow serialization to identify ERP5BaseBroken as a
PersistenBroken class.

erp5_discussion: make Discussion Post content fulltext searchable



See merge request !66

Renaming base category "journal" to "ledger"

Because "journal" is not French, and this base category can be used in different modules.

This merge request also provides a tested method in erp5_upgrader to update the objects using the "journal" category during the post-upgrade.

See merge request !54

A bug fix of erp5_core/Folder_delete



See merge request !65

Category Tool is very special for an ERP5, because it is part of the dynamic
generation of objects' properties. Setting up a property sheet on it will break
ERP5.

As the renaming feature is related to the upgrade, we will attach the constraint
on the Template Tool, as a way to group all the upgrade features at the same place