[Zope-CMF] trivial new portal folder type gives weird workflow/security behavior?

[Carl Rendell]

On Sunday, October 6, 2002, at 08:58  AM, Florent Guillaume wrote:

>> One solution would be to make _modifyPermissionMappings *not* look at
>> acquired permissions (which depend on the parents) when deciding 
>> what to
>> do to the map. Another would be to reuse the slightly different logic
>> that DCWorkflow has to change permission mappings.
>
> Note that in any case there's no way to do those role/permission 
> mapping
> changes completely cleanly until we have tri-state settings in this
> matrix (read: until Zope 3).
>
> In Zope 2 there's no way to say "from here on block this role for this
> permission". We can only say "from here on block all roles for this
> permission but allow those".
>

Understood. I can live with this and control states for children of 
the parent folderish object with a 'publish all/unpublish all' 
script if necessary.

BTW - there is an entry in collector filed by Chris I believe:

#62  Workflow on Portal Folders

Adding a (Default) workflow Portal Folder is problematic, there are 
two apparent symptoms:

1) after 'publishing' a workflowed portal folder there is a 
redirection to '/view' which, of course, results in an error;

2) there are subsequently visibility problems with a published 
folder's children.

The problem was uncovered by accident due to my poor understanding 
of how workflow functions :-) More extensive details can be found 
by following the mailing list thread:
  http://lists.zope.org/pipermail/zope-cmf/2002-September/015551.html

~C

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