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

[Carl Rendell]

Edited to reduce clutter -

I fixed the typo, and the content_status_modify script is now 
cleaner with a single statement for the reindexObjectSecurity call:

context.portal_workflow.doActionFor(
     context,
     workflow_action,
     comment=comment)

if context.isPrincipiaFolderish:
         context.reindexObjectSecurity()

if workflow_action == 'reject':
	redirect_url = context.portal_url() + '/search?review_state=pending'
else:
	if context.isPrincipiaFolderish:
		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 )

>
> 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.
>
>
>


Looking at CMFCatalogAware and the method, this is the behavior I 
would expect. Namely searching the catalog and reindexing each of 
the sub objects. After some testing it appears that all of the sub 
objects are found, and reindexed. However, the security behavior 
remains. Once the parent folderish type has been published, 
un-published objects are available to users without the permission 
to 'Access Inactive Content'.

> 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...
>

That's clear, and what I would expect. However, my testing has 
revealed when the parent folder is private, items below in a 
published or other 'Inactive' state are not visible to anonymous 
users. Actually, this sounds like traversal is catching the first 
inactive item in the chain, and blocking all sub items, much like 
.htaccess in apache.
>

Having said all of that. To me it appears we have some inconsistent 
behavior. While an inactive parent container prevents anonymous 
access to children regardless of state [what I would prefer]. A 
parent rendered active through workflow allows children in an 
inactive state to be accessed anonymously.

Of course I could have missed something.

~C

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