Hi Dieter! I believe you on the spot about it not being in the heirarchy yet. There are a couple of interesting things:

First, it is a different sort of workflow because it is automatically activated with contents being dropped in folder but
original object is deleted as part of worklow too. To start....

# Get the object and its id
image_obj = state_change.object
id = image_obj.getId()

This gives me a handle on the state change object but it is really not in the heirarchy yet. I do get an id and FTP does give me the data but not in the way I may have expected but still perhaps enough to do something with. This seems to be why I could not get the objects data yesterday. So I am instead testing request method and using request_body (context.REQUEST.BODY) to get data when PUT method is being used (since normal method getting .data attribute works fine for HTTP uploads and cut and paste into specific folder.

                        if request_method == 'PUT':
                                image_file = StringIO(str(request_body))
                                image = PIL.Image.open(image_file)
                                image_file = StringIO(str(image_obj.data))
                                image = PIL.Image.open(image_file)

The workflow has an automatic trigger from a state called preprocessed to destination state of private (since I don't want to affect all images or the regular workflow, only the images that go into a specific folder). The script is a before script that gathers information and gives info to a tool method for PIL.

With what I am doing above, I get data for PIL and I end up with my images sized and in the right places which is what I want with no 426 error. All for exception of one thing - I want to delete the object as part of the workflow since it is no longer needed. Here again I can raise 426 Error with FTP since if
I use manage_delObjects like so:

        # Delete original object from the upload folder

method it raises following traceback:

Traceback (innermost last):

    * Module ZPublisher.Publish, line 113, in publish
    * Module ZPublisher.mapply, line 88, in mapply
    * Module ZPublisher.Publish, line 40, in call_object
    * Module webdav.NullResource, line 138, in PUT
    * Module Products.CMFCore.PortalFolder, line 393, in PUT_factory
    * Module OFS.ObjectManager, line 261, in _getOb

AttributeError: A1032.JPG

I guess my question is how can you delete an object that really is not there yet, correct - and at the same time have FTP think the object has landed in the folder? If I omit my delete statement, the workflow finishes and FTP is happy - if only I were happy too because this is not quite right - even though I have my sized images and in folders and types I want, I also want the object in the upload_dir to disappear as well.

Because I already have already obtained what I need from the FTP'd file, is there a way to give the FTP process something after the PIL process to have it think it has completed its job and send a 226 Transfer complete. This way I think workflow should be happy, FTP will be happy because it gets a successful transfer, and I will be happy because there is no file in the upload directory to worry about deleting. Even it is a very different kind of situation, perhaps it can still work.


On Thursday, August 18, 2005, at 05:00 PM, Dieter Maurer wrote:

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 - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to