[Zope-CMF] More on workflow with folders

[Carl Rendell]

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