- 09 Nov, 2017 40 commits
-
-
Nicolas Wavrant authored
It is useful to save some customizations, preferences, or eve additions for test business templates This feature is managed by a new class: ObjectPropertyTemplateItem
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
bt5_prototype: Add export functions for PathTempalteItem and BusinessPackage as well as make createInstallationData more efficient
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
Problem: This is a workaround for components being unable to get registered during the tests. Explanation: After adding document component object, _p_oid is generated at the last step of commit hook. This leads to problem that _registry_dict for dynamic_class 'erp5.component.document' isn't getting updated with the _p_oid of the component created. This leads to failing of test because to validate object with same reference, the checkConsistency function checks in the _registry_dict for reference and _p_oid. Solution: Explicilty calling transaction.savepoint here generates the oid before validation, hence make it available for the registry_dict in time. But, this clearly is a workaround which is clearly not solving the real problem of why the _p_oid isn't being generated at the right step.
-
Ayush Tiwari authored
And, Patch changeObjectClass extension to remove useless attributes Copying __dict__ from one object to another brings us to situation where we don't have many objects which we don't need at all, for example, migrating objects with subclasses who were initially OFS objects and later an ERP5 object can lead to adding subobjects as attributes of the new object, which is completely undesirable. To handle this, it is important to delete the sub-objects as the attributes for those migrated classes. Old Catalog Tool didn't have portal_type attribute, so while migrating via synchronizeDynamicModule, after _bootstrap, we expect the tool to have a portal_type to finalize migration. This step is now being done only at the end of _bootstrap after we change the classes for portal_catalog and its sub-objects.
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
-
Ayush Tiwari authored
- This step is needed due to the use of BaseTool as Base class for CatalogTool due to which there were conflict between reindexObject from the Base and the one from the BaseTool.
-