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

[Carl Rendell]

Thanks for finding this! I was just looking at DefaultWorkflow and 
tracing back the conditions when your email hit. I'm interested to 
see what Shane thinks about it.

At least now I know I'm not completely crazy! I suspect that this 
was not surfaced earlier either because most users are deploying 
DCWorkflow or something other than the DefaultWorkflow and/or 
_most_ users don't have folderish types under workflow. If I recall 
correctly. It was not until CMF 1.3/a/b that this started to 
surface because to changes to the workflow tool.

My two cents:

I would not expect _any_ item which is under direct workflow 
control to acquire its workflow from parent.

However, my wish is for tools that filter a results set 
(searchResults, LazyFilter, etc) to honor workflow state for 
parents of children much like the security model.

~C

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

> Ok, I've finally gotten to the bottom of this. Note that the bug only
> appears when using DefaultWorkflow, and not with DCWorkflow.
>
> The short version is that there's a bug in the way
> utils._modifyPermissionMappings, and thus DefaultWorkflow, sets
> permission mappings.
>
> When an object is inserted into the DefaultWorkflow using 
> notifyCreated,
> the workflow sets the state to 'private' and calls
> utils._modifyPermissionMappings with the mapping:
>     {'View':                  {'Anonymous': 0, 'Reviewer': 0, 
> 'Owner': 1},
>      'Modify portal content': {'Owner': 1}}
>
> But _modifyPermissionMappings has an incorrect logic in how it tries to
> modify the existing mapping. What it does is, for each permission, try
> to find the current roles that have this permission (through
> rolesForPermissionOn), and if the desired map has to make a change then
> (and only then) the roles are updated, and set to not acquire. In our
> case, if Anonymous and Reviewer currently don't have View, and 
> Owner has
> it, then no change for that permission will happen (this is the normal
> case that's actually happening). The problem is that if later on an
> enclosing folder is changed, to allow Anonymous for instance, then
> because the object still has its original setting of having permissions
> acquired, it will become visible for Anonymous.
>
> 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.
>
> Shane, what do you think?
>
>
> Florent
>
> In article <9415BF90-D669-11D6-BF39-000393580FEA@sol43.com> Carl write:
>> On Wednesday, October 2, 2002, at 01:18  PM, Florent Guillaume wrote:
>>
>>> On Wed, 2002-10-02 at 22:12, Carl Rendell wrote:
>>>> I understand this part. What i'm not understanding right now is why
>>>> unpublished items within a published folder are being selected by
>>>> portal_catalog.searchResults() ?
>>>
>>> I don't know. You'll have dig a bit and add debugging statements
>>> so that
>>> we find out what's happening. What's the catalog entry for that 
>>> object?
>>> When does it change?
>>>
>>
>> I've done some additional testing, and now see why i'm getting the
>> 'strange' behavior.
>>
>> Here is the scenario -
>>
>> o Create folder under workflow control (Default) and leave private
>>
>> o Create sub object within the folder hierarchy (tested to various
>> levels with no change)
>>
>> o 'Publish' the folder
>>
>> o Sub object is now visible
>>
>> So why? For some reason the change to the folder workflow state is
>> also cascading down to the object and changing what it should be in
>> the allowedRolesAndUsers index -
>>
>>    ['Manager','user:x','user:y']  to
>>
>>    ['Anonymous', 'user:x', 'user:y', 'Manager', 'Reviewer']
>>
>> Makes a lot of sense why the objects are visible!
>>
>> I've confirmed this by publishing and un-publishing the sub-object,
>> which has the effect of the sub object no longer having its index
>> changed by the parent. This also explains why the
>> reindexObjectSecurity() call has little effect because it is
>> reindexing the allowedRolesAndUsers idx, which has been changed by
>> the parent.
>>
>> I'm not sure what this means now? I can see some gross work arounds
>> like checking all sub objects to see if the allowedRolesAndUsers
>> matches up with the object review_state, and then doing a resync.
>> That feels like the wrong thing to do.
>>
>> So, am I crazy or what? This thing is really baking my noodle right
>> now. Why would the workflow change sub items?
>
>
>
> --
> Florent Guillaume, Nuxeo (Paris, France)
> +33 1 40 33 79 87  http://nuxeo.com  mailto:fg@nuxeo.com
>

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