[Zope-CMF] Re: more prose about workflow changes

[Shane Hathaway]

Jeff Sasmor wrote:
> As it stands now, if you search for something (that is, using the
> text box in the top-bar) then even if a portalcontent is in an unpublished
> state it still shows up. The search.dtml method ought to be able to screen
> out unpublished stuff. Or the portal_catalog should. User's ought not to get
> links that don't work or don't take them where they expect to go.

Again, there's a bug on your site.  When everything is working right,
nothing in the "private" or "pending" state shows up in the search
results for anonymous users, nor can they get to it even via URL.  This
is accomplished through the magic of the "allowedRolesAndUsers" field of
the catalog.

> When I was designing the Blark product, I wanted to allow portal members
> to create a squishdot-like thing that anyone could post to (if the owner of
> the
> Blark allows it).  Now, if you let someone else post to what's essentially a
> specialized portal folder that you (as a Member) own you'd like to let
> them edit it, and they ought to be able to submit it for review.
> 
> Hence, they ought to be able to see if it is published or not: but this is
> their
> content in your area. So showing the review state can't be done.
> Of course, one can check the view permission for various roles and
> determine the state directly (which is what I did), but that's (maybe)
> nonportable
> to other workflows.

The right thing to do here IMHO is to make the owners of squishdots have
the "Reviewer" role within their own area.

> I can't see any real reason to keep the review state of a portal content
> item private.  And it isn't (if you're at the Python level) anyway.

It's not the review state that's private.  It's the item itself.  On a
correctly working site, anonymous users can't even *find* private
content.

> I'm not ranting about it, I can live with it the way it is. It's a minor
> tickle
> on the overwhelming goodness of the CMF. But as people like me try to
> use the CMF for whacky things that are somewhat out of scope of the
> original intent minor warts appear. So it goes.

Your input is very much valued.  I think if we could figure out what the
bug is on your site then you'll see how things are *supposed* to work.
:-)

Chris just came in here and pointed out something that might solve this:
you have a special filesystem product, right?  In the constructors, do
you call "WorkflowCore.afterCreate()"?  Currently that's the only way to
let the workflow set up the initial object permissions.  It's not fully
documented because it probably needs to be made transparent.

Shane