WIP: providesI<INTERFACE_NAME> accessors were not created for ZODB Components (!1099) · Merge requests · nexedi / erp5

WIP: providesI<INTERFACE_NAME> accessors were not created for ZODB Components

16 Apr, 2020 6 commits

ZODB Components: providesIFoo() getters were only created for FS Interfaces (MR !1099). · c86107bf

Arnaud Fontaine authored 5 years ago

Add them to BaseAccessorHolder (like `Base Category` accessors) instead of
Base class so they can be regenerated on reset while not having to remove
ZODB Components from Base class on reset.

This means that providesIFoo() will only be available on Portal Type classes
whereas before it was working for direct Document instanciation, but the latter
has been banned for several years anyway and the few remaining ones have been
fixed (23b2b5fd, e791d08a).

Also, instead of Base.provides() being a CachingMethod() (does not work with
resets), create a method dynamically on the Portal Type class (erp5.portal_type.Foo),
as not caching at all is ~18 times slower.

c86107bf

ZODB Components: Cosmetic: Refactor duplicated code. · 18f47f4e
Arnaud Fontaine authored 5 years ago

18f47f4e
TypesTool.getInterfaceTypeList(): Filesystem Interfaces were not returned. · 34fc009d
Arnaud Fontaine authored 5 years ago
```
And thus filesystem Interfaces were not displayed/selectable in BaseType_view.
```
34fc009d

erp5_certificate_authority: Certificate Authority Tool: All ERP5 objects... · 23b2b5fd

Arnaud Fontaine authored 5 years ago

erp5_certificate_authority: Certificate Authority Tool: All ERP5 objects *must* have have a Portal Type in Types Tool.

And remove hack in erp5_promise which was creating a non-Portal Type class of
portal_certificate_authority. Instead, add a depend on erp5_certificate_authority.
`providesI*` accessors are now in BaseAccessorHolder rather than Base due to ZODB
Components, this breaks reindexing (`AttributeError: providesIPredicate`).

This gets rid of:
  WARNING ERP5Type.dynamic Cannot find a portal type definition for 'Certificate Authority Tool', trying to guess...

23b2b5fd

Portal Type as Classes: ERP5Form: Instances of Documents should never be created directly. · e791d08a

Arnaud Fontaine authored 5 years ago

This has been banned since the introduction of Portal Type class. When creating
a new ERP5Form via addERP5Form/ZMI, its MRO:
  * Before:
    <class 'Products.ERP5Form.Form.ERP5Form'>
    <class 'Products.ERP5Type.Base.Base'>
    ...
    <type 'ExtensionClass.Base'>
  * Now:
    <class 'erp5.portal_type.ERP5 Form'>,
    <class 'Products.ERP5Form.Form.ERP5Form'>,
    <class 'Products.ERP5Type.Base.Base'>,
    ...
    <class 'erp5.accessor_holder.property_sheet.SimpleItem'>
    <class 'erp5.accessor_holder.property_sheet.Folder'>
    <class 'erp5.accessor_holder.property_sheet.Base'>
    <class 'erp5.accessor_holder.property_sheet.CategoryCore'>
    <class 'erp5.accessor_holder.BaseAccessorHolder'>
    <class 'Products.ERP5Type.dynamic.portal_type_class.GetAcquireLocalRolesMixIn'>
    <type 'ExtensionClass.Base'>

Thus it was missing many accessors and was working only by chance (or at least
unless these accessors were not called until the object was automatically migrated
by the next call to __setstate__). Namely, as `providesI*` accessors are now in
BaseAccessorHolder rather than Base due to ZODB Components, this breaks reindexing
(`AttributeError: providesIPredicate`).

Also, remove hardcoded _getAcquireLocalRoles() now that it is not used as a regular
class anymore. Set this on the portal type object instead.

e791d08a

erp5_core: Move `ERP5 Form` Portal Type from erp5_hal_json_style as it is used by erp5_core. · 74d022e5
Arnaud Fontaine authored 5 years ago
```
This gets rid of:
  WARNING ERP5Type.dynamic Cannot find a portal type definition for 'ERP5 Form', trying to guess...
```
74d022e5