David Pratt wrote at 2005-8-17 18:08 -0300:
Hi Dieter. Many thanks for your reply. The place in my workflow that it failed was opening the image.
IOError: cannot identify image file ... error here --> image = PIL.Image.open(original_file)
This does not look like a workflow problem. Instead, PIL seems to be unable to determine the type of image ("jpg", "png", "gif", ...). I cannot tell you why. Looking at the traceback (where is the exception raised?) and then at the corresponding code may give you a hint.
... I discovered that it does not appear possible to have a workflow act on content immediately after being FTP'd to a site without generating the 'FTP 426 Error creating file' error. If I FTP an image to the folder as Manager with copy or move permission, it will trigger 426 Error creating file and the following traceback. The workflow will work for regular operations within the portal, just not FTP.
* Module OFS.CopySupport, line 92, in manage_cutObjects
Copy Error: The action against the <em>A084.JPG</em> object could not be carried out. One of the following constraints caused the problem:i * The object does not support this operation -- OR -- * The currently logged-in user does not have the <b>Copy or Move</b> permission respective to the object.
Xssss. Almost a Windows like message :-( But, your traceback was definitely larger. Please post the whole one. Probably, your workflow gets fired too early -- at a time when the object is not yet put placed inside the Zope object hierarchy. At such a time, Zope permission system does not yet work (the permissions defined at objects in the hierarchy are passed down to lower level -- however, they can only reach objects placed in the tree). The full traceback may tell us whether this hypothesis is true. -- Dieter