[Zope-CMF] Workflow not found, problem with doActionFor()

[Florent Guillaume]

Did you checked what I suggested? What about it:

> If that's not the problem, make sure to check in what state your
> object and its portal_type really is (you can do that from the
> Workflow tab in the ZMI).

Florent

In article <7CDD7B94357FD5119E800002A537C46E2306CB@s5-ccr-r1.ccrs.nrcan.gc.ca> you write:
> Hello,
> 
> Thanks for the help ...
> 
> It's not a typo, you're just missing the rest of the script :) what I'm
> doing is converting objects created with manage_addContent (Or whatever that
> method is that the ZMI uses), with properly created ones using invokeFactory
> ... the review_state testing actually refers to the review state of the
> "original" object ...
> 
> Although I don't test for it programmatically, the default state for my CMF
> created objects is "private", and if I go through the site and look at the
> actions box, that's what they are set to, as expected. So now I need to set
> the "new" objects to the same state as it's ancestor (The only other state
> in my current workflow is "published"). And this is where I run into the
> trouble I mentionned.
> 
> It just won't work I get:
> 
> WorkflowException: No workflow provides the "publish" action.
> 
> Which is essentially NOT true, since there definitely is one (I can even do
> the publish through the actions box without problem, just not through code).
> 
> One thing I noticed while working on this script is that there seems to be
> some sort of transactional/commit behavior in Zope that I'm not aware of ?
> 
> I first ran into this when I was trying to rename a recently create object
> (I was creating the object with a temporary id, then renaming ...) ... The
> renaming wouldn't work, I kept being told the object didn't exist! (Even
> though it was very much there). I ended up going about it the opposite way,
> I rename the original object FIRST, then create the new one with it's final
> id right away, avoiding the need to rename the NEW one.
> 
> But now that I'm running into this, I can't help but see similarities in the
> behavior of the error.  If there some sort of "commit" that happens
> internally that maybe hasn't happened yet by the time I try to change the
> review state? This would explain why I can't do it in the code, but I CAN do
> it after the fact ... much like with the renaming ...


-- 
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 79 87  http://nuxeo.com  mailto:fg@nuxeo.com