Commit 3d3ec3cb authored by Kazuhiko Shiozaki's avatar Kazuhiko Shiozaki

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.
parent 63bd5a39
......@@ -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:
......
  • 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

  • There are two ways :

    • newContent(activate_kw=...) (see ERP5Type.ERP5Type.constructInstance)
    • call obj.setDefaultActivateParameterDict() directly
  • And ? How could these 2 ways happen when recurseCallMethod reexecuted itself ?

  • 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')
  • 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.

  • mentioned in commit 1f73347c

    Toggle commit list
  • @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.

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

  • A unit test is definitely needed.

  • mentioned in commit 1cd37609

    Toggle commit list
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment