Folder: call activate on the object instead of...

Folder: call activate on the object instead of portal_activities.activateObject in _recurseCallMethod().

so that activate_kw set on the object is respected.

product/ERP5Type/Core/Folder.py

@@ -449,7 +449,6 @@ class FolderMixIn(ExtensionClass.Base):
     activate_kw.update(kw.get('activate_kw', ()))
     activate_kw.setdefault('active_process', None)
     activate_kw.setdefault('activity', 'SQLQueue')
-    activate = self.getPortalObject().portal_activities.activateObject
     validate = restricted and getSecurityManager().validate
     cost = activate_kw.setdefault('group_method_cost', .034) # 30 objects
     if cost != 1:
@@ -513,7 +512,7 @@ class FolderMixIn(ExtensionClass.Base):
           del next_id[0]
       if min_depth <= depth:
         check_limit()
-        getattr(activate(container, **getActivateKw(container, recurse_activate_kw)),
+        getattr(container.activate(**getActivateKw(container, recurse_activate_kw)),
                 method_id)(*method_args, **method_kw)
       del recurse_stack[depth:]
     try:

[Julien Muchembled]

How is activate_kw set on the object ? It's important to have same behaviour whether it's the first call of recurseCallMethod or if recurseCallMethod reexecuted itself.

/cc @vpelletier

[Kazuhiko Shiozaki]

There are two ways :

• newContent(activate_kw=...) (see ERP5Type.ERP5Type.constructInstance)
• call obj.setDefaultActivateParameterDict() directly

[Julien Muchembled]

And ? How could these 2 ways happen when recurseCallMethod reexecuted itself ?

[Kazuhiko Shiozaki]

activate_kw is stored in a transactional variable cache, thus it is kept in recursively calling recurse() here. Do I miss something ?

BTW, I found that the following should be also part of this commit :

--- product/ERP5Type/Core/Folder.py
+++ product/ERP5Type/Core/Folder.py
@@ -522,7 +522,7 @@ class FolderMixIn(ExtensionClass.Base):
         raise
       activate_kw['group_method_id'] = kw['group_id'] = '' # no grouping
       activate_kw['activity'] = 'SQLQueue'
-      activate(self, **activate_kw)._recurseCallMethod(
+      self.activate(**activate_kw)._recurseCallMethod(
         method_id, method_args, method_kw, restricted=restricted, **kw)
 
   security.declarePublic('recurseCallMethod')

[Julien Muchembled]

Do I miss something ?

Mainly that _recurseCallMethod does not create all activities in a single transaction. Once a limit is reached, it activates itself and the recursion continues in a different transaction, directly from CMFActivity. What I'm saying is that your change would only work if there aren't too many objects in the tree.

I also found that I wrote the following explanation in the docstring:

In order to activate objects that don't inherit ActiveObject, only placeless default activate parameters are taken into account.

You should be able to do what you want with get_activate_kw_method_id. I admit it may be harder to use.

[Kazuhiko Shiozaki]

@jm I thought that creating activity for 'self' should happen in the first transaction thus no issue. But I am not sure if it is true. And even if it is true, still 'placeless default activate parameters' will be missing in following transactions.

[Julien Muchembled]

It's true that my comment about placeless default activate parameters is suspicious.

[Julien Muchembled]

A unit test is definitely needed.