RE: [Zope-dev] Re: RFC: backward compatibility of ps bindingsRESOLUTION
Brian Lloyd wrote at 2004-1-22 10:11 -0500: >> I did check with a fresh 2.6 xx >> A DCWorkflow script that was not not called with the version from a few >> hours ago is now called but produces the following traceback >> >> This happens when the container binding is set to "container" and also >> when it is cleared. > ... >>- > /zehnder/zehnder/portal_workflow/ZWorkflow/scripts/setTaskOwner> >>- Line 1 >> AttributeError: StateChangeInfo instance has no attribute >> 'getPhysicalRoot' This problem has nothing to do with the recent security enhancements: "StateChangeInfo" does not have a "getPhysicalRoot" attribute. It never had and it should not have... Check your "setTaskOwner" script. Almost surely, you do not want to call "getPhysicalRoot" on the "state_change" but on the affected object. -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: RFC: backward compatibility of ps bindingsRESOLUTION
Brian Lloyd wrote: I did check with a fresh 2.6 xx A DCWorkflow script that was not not called with the version from a few hours ago is now called but produces the following traceback This happens when the container binding is set to "container" and also when it is cleared. Traceback (innermost last): Module ZPublisher.Publish, line 98, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 39, in call_object Module Products.CMFCore.FSPythonScript, line 92, in __call__ Module Shared.DC.Scripts.Bindings, line 298, in __call__ Module Shared.DC.Scripts.Bindings, line 329, in _bindAndExec Module Products.CMFCore.FSPythonScript, line 126, in _exec - __traceback_info__: ({'traverse_subpath': [], 'container': , 'context': , 'script': }, (None, 'File', None), {}, (None, None, None)) Module None, line 12, in createObject Module Products.CMFCore.PortalFolder, line 362, in invokeFactory Module Products.CMFCore.TypesTool, line 824, in constructContent Module Products.CMFCore.TypesTool, line 516, in constructInstance Module Products.CMFCore.TypesTool, line 420, in _finishConstruction Module Products.CMFCore.CMFCatalogAware, line 101, in notifyWorkflowCreated Module Products.CMFPlone.WorkflowTool, line 26, in notifyCreated Module Products.CMFCore.WorkflowTool, line 362, in notifyCreated Module Products.DCWorkflow.DCWorkflow, line 367, in notifyCreated Module Products.DCWorkflow.DCWorkflow, line 440, in _changeStateOf Module Products.DCWorkflow.DCWorkflow, line 543, in _executeTransition Module Shared.DC.Scripts.Bindings, line 298, in __call__ Module Shared.DC.Scripts.Bindings, line 329, in _bindAndExec Module Products.PythonScripts.PythonScript, line 311, in _exec Module None, line 1, in setTaskOwner - - Line 1 AttributeError: StateChangeInfo instance has no attribute 'getPhysicalRoot' Robert It would be helpful if you could go through that in the debugger and see if you can get any more info - I don't see anything in this that obviously points to any of the recent security changes. That's not to say that one of those changes couldn't still be the cause, but this traceback doesn't point to anything we can look at :( Alternatively, if you can make a copy of the failing script and boil it down to the minimum possible code that demostrates something that should be working but isn't (and that excludes app-specific or Plone objects if possible so that we can turn it into a unit test) I can try to look at it here. thx, Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com Brian, I tried hard to recreate the problem in isolation but failed. So it must be something whith what we are doing. Strange that our code works fine with 2.62. thanks again Robert ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Re: RFC: backward compatibility of ps bindingsRESOLUTION
> I did check with a fresh 2.6 xx > A DCWorkflow script that was not not called with the version from a few > hours ago is now called but produces the following traceback > > This happens when the container binding is set to "container" and also > when it is cleared. > > Traceback (innermost last): > Module ZPublisher.Publish, line 98, in publish > Module ZPublisher.mapply, line 88, in mapply > Module ZPublisher.Publish, line 39, in call_object > Module Products.CMFCore.FSPythonScript, line 92, in __call__ > Module Shared.DC.Scripts.Bindings, line 298, in __call__ > Module Shared.DC.Scripts.Bindings, line 329, in _bindAndExec > Module Products.CMFCore.FSPythonScript, line 126, in _exec >- __traceback_info__: ({'traverse_subpath': [], 'container': > , 'context': at 9615280>, 'script': /zehnder/zehnder/createObject used for > /zehnder/zehnder/tasklist/Task.2004-01-21.1914/Attachments>}, > (None, 'File', None), {}, (None, None, None)) > Module None, line 12, in createObject > Module Products.CMFCore.PortalFolder, line 362, in invokeFactory > Module Products.CMFCore.TypesTool, line 824, in constructContent > Module Products.CMFCore.TypesTool, line 516, in constructInstance > Module Products.CMFCore.TypesTool, line 420, in _finishConstruction > Module Products.CMFCore.CMFCatalogAware, line 101, in > notifyWorkflowCreated > Module Products.CMFPlone.WorkflowTool, line 26, in notifyCreated > Module Products.CMFCore.WorkflowTool, line 362, in notifyCreated > Module Products.DCWorkflow.DCWorkflow, line 367, in notifyCreated > Module Products.DCWorkflow.DCWorkflow, line 440, in _changeStateOf > Module Products.DCWorkflow.DCWorkflow, line 543, in _executeTransition > Module Shared.DC.Scripts.Bindings, line 298, in __call__ > Module Shared.DC.Scripts.Bindings, line 329, in _bindAndExec > Module Products.PythonScripts.PythonScript, line 311, in _exec > Module None, line 1, in setTaskOwner >- /zehnder/zehnder/portal_workflow/ZWorkflow/scripts/setTaskOwner> >- Line 1 > AttributeError: StateChangeInfo instance has no attribute > 'getPhysicalRoot' > > Robert It would be helpful if you could go through that in the debugger and see if you can get any more info - I don't see anything in this that obviously points to any of the recent security changes. That's not to say that one of those changes couldn't still be the cause, but this traceback doesn't point to anything we can look at :( Alternatively, if you can make a copy of the failing script and boil it down to the minimum possible code that demostrates something that should be working but isn't (and that excludes app-specific or Plone objects if possible so that we can turn it into a unit test) I can try to look at it here. thx, Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )