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
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
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
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
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 -