Erik Lange wrote:
> At 10:16 PM 10/4/02, Carl Rendell wrote:
>
>> A few of us have been discussing Folders and Workflow, and I'd like
>> to get some closure on the subject.
>>
>> So far it appears that any folderish type which is governed by
>> workflow will, on its initial workflow state change (private to
>> published) change the allowedRolesAndUsers attribute for items within
>> the folder's branch.
>>
>> This only occurs on the initial state transition though. Subciquent
>> retraction/rejection and publishing does not have the same effect.
>>
>> The questions are..
>>
>> Is this a bug, or by design?
>
>
> That depends on the situation - it's all in the eye of the beholder :-)
Well I'm with Carl on this, I'm totally mystified and can't really see a
useful scenario for the current behaviour. Workflow of folders looks
like a distinctly sticky issue.
However as Erik points out it isn't actually necessary to solve this
particular problem at the workflow level, it can be readily solved as a
skin:
Erik Lange wrote:
> We've solved this in two ways:
>
> 1. A multiple publishing page, that lists all objects in a folder,
> where you can select by check-boxes,which objects (the event, the
> masterfile and the clips) the user wishes to publish (or retract, or
> hide, or make visible).
Earlier I suggested some semantics which I'd like for a workflowed folder:
chris wrote:
> 'publishing' a folder simply 'publishes' all of its children
> 'retracting' a folder similarly 'retracts' all of its children
> the 'review_state' of the folder is then calculated on the state of
> its children:
> - 'published' if all children are 'published',
> - 'private' if all children are 'private'
> - 'mixed' otherwise.
The following achives it as a skin:
--oOo--
## Script (Python) "bulk_status_check"
def sum(a,b):
if a=='': return b
elif b=='': return a
elif a==b: return a
else: return 'mixed'
state = context.portal_workflow.getInfoFor(context, 'review_state', '')
for obj in context.objectValues():
state = sum(state, obj.bulk_status_check())
return state
--oOo--
## Script (Python) "bulk_status_modify"
##parameters= redirect=1
action = context.REQUEST.action
if redirect:
context.REQUEST[ 'RESPONSE' ].redirect( context.absolute_url()+
'/publish_contents_form?portal_status_message=Status+changed.')
try:
context.portal_workflow.doActionFor(context,action,comment='changed by
bulk_status_modify')
except:
pass
objs = context.objectValues()
for obj in objs:
obj.bulk_status_modify(redirect=0)
--oOo--
publish_contents_form.pt
<html xmlns:tal="http://xml.zope.org/namespaces/tal"
xmlns:metal="http://xml.zope.org/namespaces/metal"
metal:use-macro="here/main_template/macros/master">
<body>
<div metal:fill-slot="main">
<div class="Desktop">
<h1> Publication of <span tal:replace="here/getId">Item</span>'s
Contents</h1>
<p>This page can be used to publish, or retract all of the items in this
folder.
Currently the items in this folder are in a
<b tal:content="here/bulk_status_check">unknown</b> review state</p>
<form method="post" action="bulk_status_modify"
tal:attributes="action
string:${here/absolute_url}/bulk_status_modify">
<input type="submit" name="action" value="publish">
<input type="submit" name="action" value="retract">
</form>
</div>
</div>
</body>
</html>
--oOo--
publish_content_form is then intended to be added as an action of Portal
Folders, eg 'Publish Contents'
Best regards,
Chris.