2003/09/28: This feature does not work at present and the code will be mothballed next month, assuming noone steps forward to maintain it.

(Here's some info about the new "regulations" mechanism WikiForNow implements in digital creations version of ZWiki - probably something like it will be in simon's version in not too long... KenManheimer)

This has been added for 0.10.0 but needs beta testers. To activate it, add a 'use_regulations' boolean property to your wiki folder and set it to true. Regulation options will appear on the editform. --SM

<i>Hmm. How are you using the roles below with ExUserFolder? Should these two mechanisms be used together, or is that just asking for trouble?</i>--PeterMerel

Specifying Who Can Do What in Your Wiki Pages and Folders

Wiki page and folder owners can specify which visitors to their pages can do what wiki operations with them. The regulations are expressed according to operation versus role categories, or versus specific user ids.

Every page has a regulations form with controls for the page - only the page or folder owners can change the settings, but anyone can view them - see them by following the "Advanced Actions" link in the page footer.

The following table describes the terms used in the controls. It's followed by descriptions of some ways the controls are used for common community scenarios.

<table cellspacing=20>
<tr valign="top">
<td>
<table border=1>
<tr>
<th colspan=2 bgcolor="eeeeee"> Operations </th>

</tr> <tr>

<th align="left" valign="top"> Create </th> <td>

Enable people to create pages for new wiki names. They will be presented with a <font color="green"> ? </font> question mark to create a new page with the current page as its parent. Those not allowed to create new pages from the current page will see an <font color="green"> <sup>x</sup> </font> instead.

</td>

</tr> <tr>
<th align="left" valign="top"> Edit </th> <td>
Change the text of the current page.

</td>

</tr> <tr>
<th align="left" valign="top"> Comment </th> <td>
Append comments to the bottom of the page. This is a more controlled way to get feedback than the more free-wheeling full-edit ability.

</td>

</tr> <tr>
<th align="left" valign="top"> Move </th> <td>
Rename or delete the page, or change its designated parent(s). When renaming, links to the old name will <em> not </em> be automatically adjusted to track change.

</td>

</tr>

</table>

</td> <td valign="top">

<table border=1>
<tr>
<th colspan=2 bgcolor="eeeeee"> Role Categories </th>

</tr> <tr>

<th align="left" valign="top" NOWRAP> Nobody </th> <td> Not even managers or page owners - but they can

reset the policy.

</td>

</tr> <tr>

<th align="left" valign="top"> Owners </th> <td>

The fundamental category, users with the 'Owner' or 'Manager' role, or with ownership of the page. People in the Owners category can also set page regulations, esablishing what other visitors to their pages can do.

</td>

</tr> <tr>

<th align="left" valign="top" NOWRAP> Non-Anon </th> <td> "Non-Anonymous" -

This category further extends to include any logged-in visitor.

</td>

</tr> <tr>

<th align="left" valign="top"> Everyone </th> <td>

This category further includes anonymous visitors. Indistinguishable from one another, there's no way to assign responsibility for their actions - which may sometimes be your aim.

</td>

</tr>

</table>

</td>

</tr>

</table>

<ul>
<li> Page owners can use the <strong> Additional Allowed Users
</strong> boxes to enable an operation for specific users, regardless of the Role Category settings </li>
<li> Finally, if you select the <strong> Propagate to Offspring
</strong> checkbox at the bottom of the column for an operation, then this setting will be passed to all offspring pages that you are allowed to regulate. </li>

</ul>

Page Ownership Inheritance

Page owners control the way that ownership is determined for new pages that are created from their pages.

By keeping ownership, they keep control over the way that any immediate or indirect offspring pages are used, since the ownership inheritance setting is, itself, inherited. Thus they delegate specific operations, but retain control over the policies.

By allowing ownership to the page creators, they enable the page creators to set their <em> own </em> policies - essentially, delegating complete authority over the subpages.

By selecting both - ie, original owner and new page creator getting ownership of the new page - the original owner can keep a hand in the regulations for the subpages.

Policy Scenarios

These basic operational regulations together with the ability to specify how the control over the regulations is passed on enables a wide range of policies within any region of a wiki. Page owners can establish policies for a wide range of community dynamics, from classic wiki's free-wheeling, open policies, to completely constrained. Below are some salient scenarios, within hints about implementing them.

Classic wiki -- By setting regulations wide open, but retaining ownership, all pages created from their page will be wide open, and page creators cannot change the regulations to constrain operations. The original page owner can enable or disable ZWiki enhancements, like immediate rename and delete, depending on how closely they want to emulate the classic wiki.

Perhaps more interesting, page owners can hand off control over the wiki subregions springing from their page, in finely tuned ways.

Page owner delegates control over contents of particular subpages -- By creating the pages and specifying the particular users that have (only) edit privileges there.

Page owner delegates control of subtopic or project areas -- By creating the links to the subpages for the subtopics, and arranging for the target owners to click the ? question marks and create the subpages. By granting ownership of subpages to the creators, the creators get full authority over the subpages, to change as they might wish and to set policies for delegation to others, as they wish.

Page owner opens a subtopic for a free-for-all -- By creating a subpage and enabling all operations to all visitors (or to logged in visitors, if responsibility auditing is desired), but retaining ownership for themselves. Essentially, the original page owner creates a "classic"-style subregion.

Page owner creates a discussion page -- By creating a subpage where anyone can append comments, but the page owner (and anyone they designate) has edit privileges. This way the page owner and lieutenants can edit the discussion text to make in-line response acknowledgement marks, consolidate mature discussions, etc.

By opening the 'create' privilege, in addition, the original page owner enables commentators to spawn offspring discussion pages of their own. The original owner can determine whether or not those offspring pages are constrained to the original discussion format, by deciding whether or not to retain ownership of the spawned pages...

remove ? --SimonMichael, Wed, 10 Sep 2003 03:08:00 -0700 reply

I have not heard of anyone using this in a long time. Remove this feature ?

re: remove ? --dan mcmullen, Tue, 16 Sep 2003 13:17:15 -0700 reply

no, please. this makes it possible for users to have personal space in the wiki. this could engage more folks in the collective effort. imagine it as a more flexible, open kind of blog.

(selfishly speaking, i've been looking for this capability. please don't take it away just when i've found it. :-)

re: remove ? --SimonMichael, Tue, 16 Sep 2003 19:13:30 -0700 reply

Hi Dan.. ok, feedback noted, thanks. It will carry more weight when I see you actually using this and finding it worth the trouble though.

re: remove ? --Tue, 16 Sep 2003 20:34:16 -0700 reply

albeit I don't use it or know the trouble it brings... this feature is one of two parts of the "it's a secure (if you want it)" wiki features of Zwiki. The other is Zope's granular security.

my notes so far --Thu, 25 Sep 2003 14:21:30 -0700 reply

going slowly at BillSeitz:OverlappingScopesOfCollaboration

mothballing regulations --simon, Sun, 28 Sep 2003 16:23:49 -0700 reply

We've found three ways in which regulations support is broken right now; I'll be removing and mothballing the code next month, assuming no-one steps forward to make it worth keeping. We might want to revive it in a simpler form later though.