[Zope-CMF] Re: cataloging of content inside workflowed containers

[Sam Brauer]

Tres, 
Thanks for taking the time to respond.  I have a few
rambling responses below.   Mainly I wanted to get
this stuff in the mailing list archive so that other
folks might benfit from it, although more discussion
would also be interesting.

- Sam


--- Tres Seaver <tseaver at zope.com> wrote:

> Sam Brauer wrote:
> 
> > Some time ago I found that the portal_catalog
> doesn't
> > filter out of search results published objects
> that
> > are inside private folders.   This doesn't come up
> in
> > stock CMF since Portal Folders aren't workflowed,
> but
> > it will come up if you assign them a workflow (or
> use
> > Plone which workflows Folders by default).  
> > 
> > The end result is that anonymous users (or any
> users
> > with limited permissions) can see search results
> which
> > refer to objects that they do not have
> authorization
> > to view, since the object is inside a folder that
> > cannot be traversed into.
> 
> Zope 2's traversal machinery doesn't check access
> rights on the 
> containers (by design), so I'm not sure your
> scenario is quite right 
> here.  It is perfectly possible to view content
> which resides in a 
> container you can't view.


While that is true, it is also quite likely that the
template that displays the object will attempt to
access some information about the object's containers
(such as titles and urls for breadcrumbs).  This will
fail for those folders where View and "Access contents
info" are turned off for the user's role.  
Even if those succeeded, it would be frustrating as an
end-user to try to click a link in the breadcrumb
trail and encounter an auth error.  But that's a
different problem entirely.

> 
> > I wonder if other people have encountered this
> issue
> > and how they have dealt with it.  I have tried to
> deal
> > with it by monkey-patching
> >
>
CMFCore.CatalogTool.IndexableObjectWrapper.allowedRolesAndUsers
> > such that it walks up the folder hierarchy until
> it
> > reaches the site root and makes sure that the
> given
> > role has permissions to "View" and "Access
> contents
> > information" on each folder.  This seems to solve
> most
> > of the problem, but doesn't address the
> possibility
> > where container types may have effective and/or
> > expiration dates.  
> > 
> > I tend to think it would be nice if the CMF would
> > address this whole issue (including the
> > effective/expiration twist), but I can also
> understand
> > that this might be considered more of a policy
> issue.
> > However, even if there is no one-size-fits-all
> > solution, I would be curious to hear how anyone
> has
> > dealt with this sort of issue...  or at least get
> some
> > confirmation that I'm not the only person to
> encounter
> > it.
> 
> You certainly aren't the only person to encounter
> the behavior.  The 
> absence of a widely-acceptable policy for the
> implications of 
> workflowing containers is the reason that CMF
> prevents the Folder type 
> from being workflowed.
> 
> My gut reaction is that a site or application which
> workflows containers 
> needs to enforce its own policy about the workflow
> for contents.  I can 
> see several possible alternatives:
> 
>    - Status quo:  container workflow has no impact
> on the workflow state,
>      visibility, or effective range of its contents.
> 
>    - "Pater familias":  container workflow
> supercedes / suppresses
>      separate settings for its contents (note that
> subcontainers are
>      problematic here, as they were in Roman law ;) 
> This policy is
>      actually pretty sane for a content type like a
> collector issue
>      (which actually wants to suppress even the
> cataloguing of at least
>      some of its contents).
> 
>    - "Constraint satisfaction":  the container's
> visibility / effective
>      range provide additional constraints on those
> of the children.
> 
> Note that the *correct* place to apply these
> policies is within the 
> particular workflow(s) associated with the
> container;  the scripts 
> driven by the workflow might use additional tools to
> do the heavy lifting.
> 

I see your point.  But to play devil's advocate,
consider an example where a published folder has an
effective date in the future.  No action (workflow
action or any other sort) is triggered when that
effective date is reached.   What would be the
"correct" place in that situation to apply the policy?

I've resorted to running a cron job every 5 minutes
that runs a catalog query to find folders that just
became effective or expired and call the
portal_workflow's _recursiveUpdateRoleMappings()
method on them.  I'm far from proud of this approach
however.

It seems like a better solution might be for content
to have a method that returns the max effective date
from the set of effective dates for the content and
all of its containers, and the min expiration date
from the set of expiration dates for the content and
all of its containers.  Then create catalog indices on
these (or maybe a Daterange index on both) and use
that instead of the normal effective and expiration
indices when running a catalog query for users without
the "Access inactive portal content" permission.  Or
something similar... I suppose I could override
CatalogTool.searchResults() with my own implementation
that did this.  
In that case, whenever a container's dates change, I
would have to be sure to recursively reindex the
container's children.  

I'm sure there are other possible approaches, as well
as other possible policies.


> Tres.
> -- 
>
===============================================================
> Tres Seaver                               
> tseaver at zope.com
> Zope Corporation      "Zope Dealers"      
> http://www.zope.com
> 
> _______________________________________________
> Zope-CMF maillist  -  Zope-CMF at lists.zope.org
> http://mail.zope.org/mailman/listinfo/zope-cmf
> 
> See http://collector.zope.org/CMF for bug reports
> and feature requests
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com