[Zope] Workflow question

David Pratt fairwinds at eastlink.ca
Thu Aug 18 19:57:06 EDT 2005


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)
			else:
				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
	upload_dir.manage_delObjects([id,])

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.

Regards,
David


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
> tree).
>
> The full traceback may tell us whether this hypothesis is true.
>
>
> -- 
> Dieter
>


More information about the Zope mailing list