www.squeakworld.com!

Stefan Matthias Aust sma at 3plus4.de
Mon Jun 5 11:01:36 UTC 2000


At 16:21 01.06.00 -0400, Mark Guzdial wrote:

>>Is there an access control list based user management in Swiki already?
>
>I don't know because I don't know what that is :-)

I know Zope (python based dynamically web site builder tool with a large 
user community) which has something that I tried to described with the 
above buzzwords.

Zope has users and groups of users with rights similar structured as 
unix.  Users or groups can read and/or write pages.  Rights are assigned 
for realms, typically folders and their subfolders - I think.  You can also 
have the right to assign rights. This allows a hierachical organization of 
projects, with people who get responsibility assigned which again can 
delegate these responsibilities.

As a Swiki hasn't a hierachically structured set of pages, this isn't 
probably applicable.  Still, one could have groups of users who are allowed 
or forbidden to read or write certain pages - perhaps identified by keyword 
or a regex.

>We have had various protection schemes in Swiki.  (While only two years 
>old, it's evolved alot at Georgia Tech -- couple thousand student and 
>faculty users, over 120 Swikis, etc.)  We've tried some where users had 
>particular reading vs. writing vs. appending capabilities.

Yes, appending is very important.  It's nice if you can add comments to a 
page but you don't want that people can edit other people's comments.  I 
didn't know that the current swiki has this feature.

>   In general, we've found them more interface trouble than solving real 
> problems.  Our current scheme is that:
>- Any page can be locked with a password, and
>- A whole Swiki can be placed behind user authentication

The current scheme might work in an environment where everyone wants to 
cooperate.  However, depending on the audience and context, sometime, 
you'll have to face the problem that too much freedom can lead to destruction.

I know that the Dolphin people lost all their stuff a number of times at 
least one time because somebody destructively edited pages.  The other 
times, they assume (I heard) that a search robot tried to follow "delete 
this page" links ;-)

Regarding context.  If you think of an intranet which has to store 
important documents, transcripts of project meetings for example.  Now 
imagine that a project had to be canceled and everyone is looking for 
somebody to blame for that.  Now, surprisingly, the swiki-stored transcript 
had changed, making somebody say something he never said.  Before you can 
argue that old versions are also stored and that he probably didn't change 
it to his own disadvantage, he got fired by management.  IMHO you have to 
trust the information every time - and I want to read the name of the 
editor and be sure that's only he who write this or have a clearly stated 
notice that nobody is responsible for a certain part of information.

>This works pretty well, but more advanced schemes are certainly 
>possible.  Of course, none of our users have tried to produce a news site, 
>so your demands may be greater.

Probably, but hopefully we can change (evolve) a swiki for these needs.

bye
--
Stefan Matthias Aust  //  Bevor wir fallen, fallen wir lieber auf





More information about the Squeak-dev mailing list