[Zope-PTK] Catalog system

[Mike Pelletier]

On Fri, 14 Jan 2000, Paul Everitt wrote:

> To clarify: people have to ask that an object be registered in the
> catalog.  Once it is registered, all subsequent changes are automatic.

    Yes.  I don't like that there isn't a way to disallow a user from
being able to change the content of a public object without needing the
new content be approved.  I would like to address that in the new system.  

    It could be a matter of permissions.  You would need the 'change
public object' permission, or the object would become private when you
changed it.

    It could be even more fine-grained-- when reviewing a request, the
reviewer could have the option to catalog the object until it changes, or
forever.

> Also, the concept of "approval" should extend _not_ just to whether an
> object is in the catalog and placed in other parts of the site, but also
> whether its contents can be displayed.

    Yes, if you can't find it, you can't see it even if you know the URL.

> >     In the system I plan to implement, all objects would be cataloged by
> _Including_ the content of the objects?

    That was my intent.  Actually, this is made irrelevant if we only use
one catalog (below).

> Ugh, multiple catalogs sounds fishy.

    Hmm, I suppose that I'm really not trying to do anything that couldn't
be done with a single catalog.  What's really needed is a catalog object
that can filter searchResults based on the user's permissions and each
object's reviewing state.  Things like editors' picks could be done more
easily with object properties.

    Alright, then, I think it would be cleaner if I could get away with
one catalog object that can do those things.  That vastly simplifies what
objects have to be responsible for-- they just make sure the catalog is
always up to date.  They can look at their own reviewing state to
determine whether the user is allowed to view them.  The catalog will
index the state, so it will be able to easily filter out inappropriate
material.  I'll just have to extend searchResults.

    Yeah, that's way better!

    Another advantage over the present system-- at the moment, we live in
constant fear of something bad happening to the SiteIndex.  It's the only
place the reviewed state is stored, so if it is accidentally cleared we're
buggered.  With the new system, oh well, the catalog's been cleared, index
everything again and you're back where you left off.

> >     It is also intended that an object's cataloged status should inform
> > it's security policies-- if an object you do not own is not cataloged in
> > any catalogs you have access to, you cannot access that object.
> 
> Can you explain how this is better than the current implementation?

    I wish to eliminate the potential for abuse by members.  I also want
managers to have access to a catalog with every object in it.  

    Presently, Members can abuse Zope.org by--

  - Adding abusive content and not cataloging it.  They can then publish
    the URL elsewhere.
 
  - Adding acceptable content, having it reviewed and then replacing it
    with abusive content.  This is especially bad, because their content
    could very well be your front page headline.

    The new implementation solves this with security checks against the
user's permissions and the object's reviewed state.  Managers will have
some sort of ability to ensure that changed content loses it's reviewed
state.

    Here's an idea, though perhaps one for the future-- Once an object is
'public', all changes to it automatically get made in a version.  Only
reviewers would have the ability to commit the version to the public
object.

    Thanks for getting me off the idea that I needed multiple
catalogs.  That was where the largest pains came from with Zope.org's
catalogs.

-- 
Mike Pelletier                          email: mike@digicool.com
Mild mannered software developer          icq: 7127228
by day, super villain by night.         phone: 519-884-2434