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

[Florent Guillaume]

On Mon, 2002-09-30 at 00:08, Carl Rendell wrote:
> I've been working with the same sort of issues, and have tried 
> adding context.reindexObjectSecurity() within my modifications to 
> content_status_modify, but it does not seem to have the desired 
> effect -
> 
> Modified code:
> 
> context.portal_workflow.doActionFor(
>      context,
>      workflow_action,
>      comment=comment)
> 
> if workflow_action == 'reject':
> 	redirect_url = context.portal_url() + '/search?review_state=pending'
>          if context.isPricipiaFolderish:

typo: pricipia

>                  context.reindexObjectSecurity()
> else:
> 	if context.isPrincipiaFolderish:
>                  context.reindexObjectSecurity()
> 		redirect_url = '%s?%s' % ( context.absolute_url()
>                                    , 'portal_status_message=Status+changed.'
>                                    )
> 	else:
> 		redirect_url = '%s/view?%s' % ( context.absolute_url()
> 		                              , 'portal_status_message=Status+changed.'
> 		                              )
> 
> context.REQUEST[ 'RESPONSE' ].redirect( redirect_url )
> 
> reindexObjectSecurity() - in CMFCore.CatalogAware - appears to 
> recurse through all object within the given context by doing a 
> catalog search, but it does not seem to be changing the security 
> context.

It recurses and then calls catalog.reindexObject(ob,
idxs['allowedRolesAndUsers']) which should reindex what CMF sees of the
security (in the catalog). It doesn't actually change any security
settings of course, that's not its intent.

The goal is that if, for instance, the folder has a new local role
"Reviewer" for user "foo" then this local role is also true for all
subobjects (local roles are inherited) so the CMF catalog has to be
aware of that so that if a Reviewer searches for documents it will find
those under the folder.

But if you only rely on role/permission mappings, be aware that
subobjects still have their own role/permission mapping set by their
workflow, and the fact that their private containing folder now has View
disabled for Anonymous can't do anything to prevent a published document
from having View allowed for Anonymous...

So if you require that "publish" of a folder have additional semantics
on the children, that's an entirely different matter.

Actually DCWorkflow's permission settings is not flexible enough to do
that easily (its modifyRolesForPermission only set or resets the full
role+acquisition mapping for a permission), you'd like to be able to
tweak a single cell in the role/permission matrix -- and you'd
especially like a tri-state (do-nothing/block/allow), like in Zope 3.


Florent
 
-- 
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 79 87  http://nuxeo.com  mailto:fg@nuxeo.com