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
The full traceback may tell us whether this hypothesis is true.
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -