[Zope-PTK] Workflow - security model

[Paul Everitt]

On 12/4/00 12:48 AM, "Jay, Dylan" <djay@avaya.com> wrote:

> 
> I've been thinking about how I want to implement a content management site
> for project related stuff here at work. The more I think about it the less I
> see the worflow model for PTK as useful. As I understand it PTK workflow
> works like this. Most content is created in each users home directory.
> Anyone can view this however when someone wants to make this public they
> make a request. This results in a mail  or similar to someone who approves
> it. This results in the content being catalogued and therefore hooked into
> search mechanizm.

Hmm, two parts of this are wrong.  First, the content doesn't have to be
created in the member's folder.  If the member has permission in a folder
that they are browsing a page, they can open the folder to create new stuff.

Second, there isn't a mail being sent.  People request that something be
reviewed.  People with reviewer-type roles then see in the toolbox a notice
that they have something that needs to be reviewed.

> My problem is this. This only works if content is based in members folders
> and is only discoverable via the catalogue. I was thinking a site where each

The former is not true, that latter is true.

> project had a folder that contained project specific information... wiki's,
> pages requirements docs etc. Different people could have permission to edit
> different things and some people could have permission to edit but those

That's true.  The _nice_ thing about the catalog is that people can make
changes that are indexed, but they're the only ones that see their changes,
index included. (I'm disregarding for the sake of the argument the problems
cataloging has with locking.)

However, the scenario you describe turns that strength into a weakness.  You
don't want the world to see the changes to the document that are in the
version, but you want part of the world (the reviewers) to see the changes
to the metadata made in the version (the request to be reviewed).

Hmm, that's tricky.

> changes don't become public until it has been authorized. If you only have
> one version of a document that can be edited then the cataloguing trick
> isn't going to cut it. Zope already has a versioning system. How about tying
> in workflow to the versioning system. Someone only has permission to edit
> something in a version. These changes are insulated from other people. When
> it comes time they want to make those changes public then they request
> authorization. This notifies one or more authorizees who then can review the
> changes and accept. Accepting saves the version and therefore makes it
> public. You could also do any catalogue updating at this time also. The
> great thing about this model is it will work for any kind of content not
> just stuff that relies on non-publishing via obscurity. The problem is I
> can't see how to set permissions such to allow a user to do certain actions
> but only in a particular version. I suspect this is a major changes to
> Zope's security model. Anyone got any ideas on how to do this?

If you are going to allow multiple people to make independent changes,
you'll also have to have some diff-and-merge capability.  Of course this
gives zero help on binary things like gifs, and very little help on
tag-oriented things like XML.

Still, the points you raise are really interesting and certainly valid.
Looks like we need to make Zope a Subversion server, so we'll have to add
change sets and diffs. :^)

--Paul