[Zope-PTK] Debugging PTK II

Shane Hathaway shane@digicool.com
Wed, 16 Aug 2000 10:05:05 -0400


Fabio Forno wrote:
> 
> Fabio Forno wrote:
> 
> > > Actually there isn't supposed to be a comment attribute.  The comment
> > > is supposed to be added to the "review history".  You may want to look
> > > into getting that functionaliy back in there.
> >
> > I'm considering it.
> >
> Was it left out for some particular reason, or it is just one of the
> "ToDos"? ;)
> If the second option is true I'll post the code I've added to manage it.

Yep, it's on the todo list.  Send what you've got.

> > Today I had problems with the catalog (I've seen the same problem in the
> > bug tracker): when called with no arguments the REQUEST object is None
> > and all the portal objects are returned. Calling it with REQUEST as
> > parameter it warks partially (apparently the Manger can search on all
> > docuements, a member on his owns, a guest on nothing)
> >
> 
> I think I've solved the problem, there is nothing wrong with the
> catalog. In the PortalContent.allowedRolesAndUsers method we should test
> also the review_state for the View permission. At the end of the method,
> before the return, I've added this test for the review_state.
> 
> if permission=='View' and self.review_state=='published' and \
>             'Member' not in allowed:
>             allowed.append('Member') # append also 'Guest' if you want
> 
> People who have already indexed contents should reindex everything to
> make the catalog notice the changes (for this purpose I think it should
> be nice to add somewhere a method to reindex everything or just some
> portal content categories; I'm going to add it in my portal, if you're
> interested I'll post the code)

I'm glad you found a way to solve this problem but we've been pushing
for a better solution to the publishing permission dilemma.  The change
you suggested above, without some change to the permissions mechanisms,
would make it so that even though members are allowed to view the
object, they can't search for it.  We need to maintain consistency.

To maintain that consistency, allowedRolesAndUsers() must return a
complete list of roles and users allowed to view an object regardless
of its publishing status.  If there is a bug in its current way of
accomplishing that, then it needs to be fixed.  In my limited testing
it always included "Anonymous" in the list of roles allowed to view the
object.

Now, it makes sense for a change in the publishing status to generate a
change in the effective permissions on an object.  Formerly, to solve
this problem PTK would manually change the role to permission mappings
on an object when its review_state was changed.

This is debatable, but I believe it would be more sensible to
physically move the object to a "published" area and leave its role to
permission mappings alone.  The object would inherit the permission
settings of the containing folder.  This would have the added benefit
of making PTK seem more like a publishing framework.

Comments?

Shane