[Zope-PTK] Workflow - security model

Jay, Dylan djay@avaya.com
Tue, 5 Dec 2000 09:50:28 +1100


> -----Original Message-----
> From: Paul Everitt [mailto:paul@digicool.com]
> Sent: Monday, December 04, 2000 10:32 PM
> 
> 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.

ok. The main crux of the problem that I see is this. PTK currently works on
a create/review/publish workflow. But what happens when you want to
create/review/publish/revise/review/publish etc? When you revise the content
it is still accessable from searching the catalogue and thus people can view
it. However what they are viewing is the revised content BEFORE it has been
reviewed. This makes the review process very weak.
 
> > 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.)

Your saying that if I edit something in a version and then re-catalogue it
then both the object and the catalogue become exclusivly locked? That is
pretty damm ugly.
 
> 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.

I have seen a few merge/diff utils for XML. Have yet to see how well they
work however.

> 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. :^)

Personally I think that branching is long long over due not only for content
managment but for straight development. We tried constructing a demo in Zope
for our project with just two developers. This was bearable but any more
would have lead to way to many "Can you check in your change so I can make a
change becuase you have X locked" conversations. Any version control system
that doesn't have branching is not scallable. I'm not saying that merging is
an easy problem but it is a problem that has been tackled by version control
system for a long time. CVS does a good enough job. It simply comes down to
making the merger aware of the decisions about the merge at the time of the
merge.

PS. On a mildly related note. We are not progressing with Zope for our
product despite the possibility of having to reproduce some of Zopes
functionality in Java (mainly security and undo of some kind of database
backend). The main reason for this was lack of control over the code. We
have plenty of tools for doing software process using CVS for doing code
reviews and merging etc. I can see no un-dodgy way to let code that resides
in the the ODB to participate in this. What is needed is a full file per
object based ODB implementation or something. This again runs into the same
problem of "What about bizzare pickled object data?". And how would you
match zope users to CVS users? And versions? How would changes in the file
system get back into Zope? 

I'm not sure that reproducing CVS inside Zope is the answer.

Anyway just some thoughts but I really think that giving developers more
control of code at least in a development environment is very important
problem that is impeding the uptake of zope. People like files. They trust
them. Other tools work with them well.


> --Paul
>