[Zope-CMF] Re: More on workflow with folders

[Carl Rendell]

Some additional testing on this configuration:

Mac G4 OS X 10.1.5
Python 2.1.3
Zope 2.5.1
CMF 1.3
DCWorkflow 0.4.2

As a deep test, I completely rebuilt my Python and Zope 
environments from source. In addition, I grabbed a set of python 
and zope installs built specifically for my platform, and tested 
against those.

With the rebuilds from source, I continue to experience the same 
behavior. However, with the installs build for the OS X platform, 
the issues seem to be resolved. Of course I need to look deeper 
into the differences, but it seems to have cleaned up what ever 
dependency DCWorkflow had with the zope instance.

FYI.. I was having issues testing with Plone ( thought I would be 
thorough ), and those were resolved with the OS X builds as well.

More on Folders

I created a few workflows for the folder conditions using 
DCWorkflow instead of the standard CMF default workflow. So far, I 
have not run into _any_ of the issues described in the first thread 
concerning workflow and folders.

It is premature on my part to recommend using DCWorkflow for all 
folder cases yet, since there is still a lot of testing to do. 
However, I have not run into any issues so far. For Chris and 
others who might be wrestling with this issue. Here is my 
DCWorkflow configuration:

1. in the portal_workflow tool create new workflow (contents, Add 
Workflow)

2. select "default_workflow (Web-configurable workflow [Revision 2])"

3. click on the 'states' tab in your new workflow, and remove the 
'pending' state

4. click on the 'private' state and select 'show (Member makes 
content visible)' from the possible transitions list

5. go back to the states tab, and select the 'visible' state from 
the list

6. remove 'submit' from the possible transitions list

7. once again in states tab, select 'private', and click 'Set 
Initial State'

This is the same setup used for folders in Plone, and so far seems 
to work perfectly for my conditions.

~C

On Monday, October 7, 2002, at 09:41  AM, Carl Rendell wrote:

> Now that the behaviors associated with the default CMF workflow 
> and folderish types is well understood... I decided to explore the 
> same situation using DCWorkflow.
>
> As it turns out, there _are_ issues trying to use workflow for 
> folderish types with DCWorkflow as well.
>
> Config -
>
> Zope 2.5.1
> CMF 1.3
> DCWorkflow 0.4.2
>
> Conditions -
>
> All of this is conducted using the "CMF default workflow 
> [Classic]" DCWorkflow to compare behaviors with the default 
> workflow bundled with CMF
>
> Programmatically create a nested folder and content structure with 
> the parent folderish object under workflow control
>
> WF = Workflow controlled
>
> Parent folderish [WF] private --|
>                                 | -- standard folder -- |
>                                                         | -- link 
> [WF] published
>
> The hierarchy is created, and the link within the standard folder 
> is published. Now it gets interesting when the parent folder is 
> published.
>
> -- folder_contents of standard folder --
>
> Attempting to view folder contents of the standard folder raises 
> the TALES error:
>
>  Error Type: TALESError
> Error Value: exceptions.SystemError on NULL result without error 
> in call_object in "standard:'items/isPrincipiaFolderish'", at line 
> 49, column 9
>
> The last piece of the traceback is interesting
>
> (Info: items)
>   File 
> /Applications/ploneZope/lib/python/Products/PageTemplates/Expressions.py,
>  line 336, in restrictedTraverse
>     (Object: issues_log)
>     (Info: {'path': ['isPrincipiaFolderish'], 
> 'TraversalRequestNameStack': []})
>   File 
> /Applications/ploneZope/lib/python/Products/PageTemplates/Expressions.py,
>  line 354, in validate2
>     (Object: issues_log)
>
> Deleting the link item within the folder allows folder_contents to 
> work normally.
>
> -- Adding item (link) to child folder and publishing the item --
>
> You may add a new item to the child folder, but attempting to 
> publish the item yields another error:
>
> Error Type: SystemError
> Error Value: NULL result without error in call_object
>
> With the end of the traceback -
>
> File 
> /Applications/ploneZope/lib/python/Products/CMFCore/WorkflowTool.py, 
> line 309, in doActionFor
>     (Object: portal_workflow)
>   File 
> /Applications/ploneZope/lib/python/Products/CMFCore/WorkflowTool.py, 
> line 642, in _invokeWithNotification
>     (Object: portal_workflow)
>   File 
> /Applications/ploneZope/lib/python/Products/CMFCore/WorkflowTool.py, 
> line 704, in _reindexWorkflowVariables
>     (Object: portal_workflow)
>   File 
> /Applications/ploneZope/lib/python/Products/CMFCore/CMFCatalogAware.py, 
> line 68, in reindexObject
>     (Object: issues_log)
>   File 
> /Applications/ploneZope/lib/python/Products/CMFCore/CatalogTool.py, 
> line 262, in reindexObject
>     (Object: portal_catalog)
>   File 
> /Applications/ploneZope/lib/python/Products/CMFCore/CatalogTool.py, 
> line 232, in catalog_object
>     (Object: portal_catalog)
>   File 
> /Applications/ploneZope/lib/python/Products/ZCatalog/ZCatalog.py, 
> line 480, in catalog_object
>     (Object: portal_catalog)
>   File 
> /Applications/ploneZope/lib/python/Products/ZCatalog/Catalog.py, 
> line 367, in catalogObject
>   File 
> /Applications/ploneZope/lib/python/Products/PluginIndexes/KeywordIndex/KeywordIndex.
> py, line 67, in index_object
>     (Object: allowedRolesAndUsers)
>   File 
> /Applications/ploneZope/lib/python/Products/CMFCore/CatalogTool.py, 
> line 56, in allowedRolesAndUsers
>
> If the Parent folder is retracted (made private), the item can be 
> published without error. However, you then get back into the first 
> error condition.
>
> Actually, given the issues with folders and the workflow I'm not 
> completely surprised by this. It would seem that there are many 
> complex issues using workflow with folders.
>
> ~C

Carl E. Rendell
Solution43
Information Distribution Consulting        |   "Ahhhh the power of
cer@sol43.com                              |    acquisition"  - Chef Z
>