[Zope-CMF] more prose about workflow changes

Jeff Sasmor jeff@janix.com
Wed, 2 May 2001 15:01:51 -0400


Hi Shane, replies inline:
Jeff Sasmor

"Shane Hathaway" <shane@digicool.com> wrote in message
news:3AF04F4C.8DB2165A@digicool.com...
> Jeff Sasmor wrote:
> >
> > I disagree, too.
> >
> > What would be nice would be to change the default workflow
> > so that **Determining** the state of an object would be publicly
> > accessible.  Right now AFAIK that only is possible for the
> > owner of a CMF content type (or a manager or a reviewer).
>
> How does that make sense?  If an object is in the "private" state, other
> users can't even access the object itself let alone ask it for its
> state.


Sorry, perhaps I wasn't clear.  I found it difficult to so some things
_because_  I couldn't access it's private/pending/published state.

Example 1:

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.

The changes I suggested (unless I am wrong, I admit to not having tried it)
would at least make it feasable to find out whether something is or is
not published and not give someone a 'bad' link to click on.

Example 2:

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.

And so on.....


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.

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.

>
> > Regarding self-reviewing, it can be done on a case by case basis by
> > setting a particular member's Member folder (or a particular subfolder)
> > Review permission on.  I can't imagine that you'd want to allow
> > self-reviewing
> > for anyone who joins a portal. Sounds like a prescription for massive
porno
> > uploads to me.
>
> I didn't suggest self-reviewing.  I suggested matching zope.org status
> quo.  On zope.org, when you add content, anyone can get at it, but no
> one can *find* it unless they know the URL.  Reviewing makes it
> findable.
>


OK, I misunderstood.  However, on the CMF as it stands now you can find
all sorts of stuff just by searching, regardless of status. From a user's
point
of view why should s/he get a link to click on that will take them to a
login screen
or give an access error? It's confusing.