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

@nexedi provideI<INTERFACE_NAME> (such as providesIPredicate) accessors are currently generated by importLocalInterface() and then set on Base class. These accessors were not generated for ZODB Components, so this MR is about fixing that. All Unit Tests and CodingStyle Tests pass.

As these accessors need to be re-generated on reset, I put them in BaseAccessorHolder. For unification sake, I moved accessors of filesystem Interfaces from Base to BaseAccessorHolder. While doing so, I found out that ERP5Form and CertificateAuthorityTool were still being created by Document instanciation directly (which has been banned since we moved to erp5.portal_type) rather than through newContent() (or constructInstance()), so I have fixed that and added proper Portal Types in portal_types for ERP5 Form in (moved from erp5_hal_json_style to erp5_core) and Certificate Authority Tool. At the same time I got rid of direct Document instanciation, I removed _getAcquireLocalRoles() hardcoded methods on these Documents (added by @vpelletier in 58d4ab8e).

@rafael Is that okay for you that erp5_promise now depends on erp5_certificate_authority_tool (where portal_types/Certificate Authority Tool and portal_certificate_authority are)? BTW, this is unrelated to this MR but I wanted to ask: I have heard from @jerome that Certificate Authority Tool is supposed to superseeded by Caucase so it is probably not worth it migrating it to ZODB Components?

@nexedi `provideI<INTERFACE_NAME>` (such as `providesIPredicate`) accessors are currently generated by `importLocalInterface()` and then set on `Base` class. These accessors were not generated for ZODB Components, so this MR is about fixing that. All Unit Tests and CodingStyle Tests pass.

As these accessors need to be re-generated on reset, I put them in `BaseAccessorHolder`. For unification sake, I moved accessors of filesystem Interfaces from `Base` to `BaseAccessorHolder`. While doing so, I found out that `ERP5Form` and `CertificateAuthorityTool` were still being created by Document instanciation directly (which has been banned since we moved to `erp5.portal_type`) rather than through `newContent()` (or `constructInstance()`), so I have fixed that and added proper Portal Types in `portal_types` for `ERP5 Form` in (moved from `erp5_hal_json_style` to `erp5_core`) and `Certificate Authority Tool`. At the same time I got rid of direct Document instanciation, I removed `_getAcquireLocalRoles()` hardcoded methods on these Documents (added by @vpelletier in 58d4ab8efef748f522b3eaaecba3dc1133c99e72).

@rafael Is that okay for you that `erp5_promise` now depends on `erp5_certificate_authority_tool` (where `portal_types/Certificate Authority Tool` and `portal_certificate_authority` are)? BTW, this is unrelated to this MR but I wanted to ask: I have heard from @jerome that `Certificate Authority Tool` is supposed to superseeded by Caucase so it is probably not worth it migrating it to ZODB Components?