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

[Florent Guillaume]

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