TODO: update message. old message below (scope and implementation changed since we cover
original Products.*.Document and don't do newTempX )

---

make Products.ERP5Type.Document a dynamic module

Historically all document classes from Products/*/Document/*.py and from
$INSTANCE_HOME/Document/*.py were dynamically loaded in
Products.ERP5Type.Document namespace and objects in ZODB were instances
of Products.ERP5Type.Document.*.* classes. This allowed moving the
python code from one product to another without having to wory about
persistent references in ZODB.
This was done in Products.ERP5Type.Utils.importLocalDocument which was
used for Products/*/Document/*py and $INSTANCE_HOME/Document/*.py but
that was never the case for document components - they are loaded on demand.

When "portal types as classes" have been introduced, we used a new
indirect erp5.portal_type namespace, for similar reasons as the
Products.ERP5Type.Document namespace. The approach to migrate existing
documents was to hook the loading from ZODB ( Base.__setstate__ , monkey
patched from Products/ERP5Type/dynamic/persistent_migration.py ) to
replace the class from the old Products.ERP5Type.Document.* by its
corresponding erp5.portal_type.* class.

This was working fine to migrate documents whose classes were defined in
Products/*/Document/*.py, but now that these classes have been moved to
document components, this does not work anymore, because unlike when
loading a document class from Products/*/Document/X.py we don't create
the corresponding Products.ERP5Type.Document.X module when loading from
X component. As a result, existing documents of class
Products.ERP5Type.Document.X.X which did not get a chance to be migrated
before X was moved to component were now broken. In the observed case,
there was several Address, Telephone or Email created ~10 years ago.

These changes address this issue by making Products.ERP5Type.Document a
dynamic module, ie. changing the previous beaviour of copying all
document classes to Products.ERP5Type.Document by introducing a module
that will dynamically lookup the document classes on demand, first from
erp5.component.document modules, then falling back to the legacy
document classes registry (populated at startup from
Products/*/Document/*.py and $INSTANCE_HOME/Document/*.py)

A side effect of this is that newTempX constructors are now created from
document components as well (but they are still deprecated because their
behavior is really strange: when you call newTempX - X is the name of a
document class, which has a portal_type attribute and newTempX create an
instance of the portal type defined on that class, but the portal type
might be referencing anothing class)