Mailing List Archive

Mike Pelletier wrote:
> I am planning to deviate from Zope.org's system of cataloging items.
> On Zope.org, when a catalog request is made the object is cataloged by the
> 'UnreviewedIndex' catalog. When it is approved, it is removed from that
> catalog and placed in 'SiteIndex'. Objects are not automatically
> cataloged anywhere.

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

> I wish to have better access to all the objects on the portal as a
> manager. I also want objects to have a history of their catalog requests
> and resolutions.

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.

> In the system I plan to implement, all objects would be cataloged by

_Including_ the content of the objects?

> the master catalog on creation and each time they change. Only managers
> should have permission to search this catalog. When an object's catalog
> request gets approved, it is added to a public catalog. As a possible
> embellishment, there could be additional public catalogs such as 'Editors
> Picks', or one for content suitable for children, or anonymous users, or
> paying users, or whatever. There will be a property on the Member object
> which determines which catalog (possibly catalogs) the member is to use.

Ugh, multiple catalogs sounds fishy.

> The actual [un]catalog interface and methods will be done in a ZClass,
> 'CatalogManager'?, which will be a component of each PortalContent
> object. Each time the content changes, this class is notified so that it
> can decided whether the object should be updated in the catalogs, or
> perhaps removed from some catalogs as policy dictates. It also records
> all changes in catalog states, all catalog requests, and all reviewer
> actions (including comments and correspondence). I do not want the user to
> have to explicitly update the catalog, though they may have to issue a new
> request depending on the policy.
>
> 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?

--Paul

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

Hello,

I hope you don't mind the intrusion, but Paul let me in :)

----- Original Message -----
From: "Mike Pelletier" <mike@metamike.net>
To: "Paul Everitt" <paul@digicool.com>
Cc: <zope-ptk@zope.org>
Sent: Friday, January 14, 2000 12:55 PM
Subject: Re: [Zope-PTK] Catalog system


> 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.

You just negated a message that I was about to send :)

The crux of my message was that News Items were different from regular items
because they don't need to be "maintained" after they are created, and so on
and so forth, touching upon exactly what you mention above. By eliminating
the above possibilities for all items, I think it's fine for News to be
treated like the rest...

With the exception that you probably don't want News Items to be deleted
without manager approval, because they are quite possibly part of an RSS
story flow that is showing up on sites all over the place, and you may not
want the link to suddenly just go dead...

> 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.

This idea is nice, just as long as the version doesn't lock the whole
catalog (as it does now).

In general, I'll shut up until I've had a chance to look things over more.
Just wanted to say that I think your line of thinking here is great!

BTW, we'll be using PTK components for something very different from
Zope.org. But, it looks like the things you all have in mind are quite
flexible.

Kevin

On Fri, 14 Jan 2000, Kevin Dangoor wrote:

> Hello,
>
> I hope you don't mind the intrusion, but Paul let me in :)

Not at all, intrude all you like. I can certainly use the input.

> The crux of my message was that News Items were different from regular items
> because they don't need to be "maintained" after they are created, and so on
> and so forth, touching upon exactly what you mention above. By eliminating
> the above possibilities for all items, I think it's fine for News to be
> treated like the rest...
>
> With the exception that you probably don't want News Items to be deleted
> without manager approval, because they are quite possibly part of an RSS
> story flow that is showing up on sites all over the place, and you may not
> want the link to suddenly just go dead...

Very good points, I had not even considered external syndication. I
definitely see good reasons for wanting any changes made to News Items be
very apparent as changes, such as restricting the user to append-only
changes, if changes should be allowable at all. The portal objects need
to be fleshed out considerably yet.

> This idea is nice, just as long as the version doesn't lock the whole
> catalog (as it does now).

Indeed, I'm going to need to crack that nut sooner or later.

Thanks for your encouragement!!

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