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

[chris]

Carl Rendell wrote:

> Thanks for finding this! 

Yep, nice one Florent! I've certainly learned a lot about workflow as 
the result of this thread ;-)

Regards,
Chris.


> 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
>
>
> _______________________________________________
> Zope-CMF maillist  -  Zope-CMF@zope.org
> http://lists.zope.org/mailman/listinfo/zope-cmf
>
> See http://collector.zope.org/CMF for bug reports and feature requests