I wanted the ability to lock certain pages so that only an Admin could change them. Here's my code (added right after the initialize call in edit):

      if (&wiki::getPrefsValue("LOCKED") =~ /(^|(\s+))$topic\s*(,|$)/) {
       if (&wiki::getPrefsValue("ADMINS") !~ /(^|(\s+))$userName\s*(,|$)/) {
        my $tmpl="";
        print "Content-type: text/html\n\n";
        $tmpl= &wiki::readTemplate( "adminonly" );
        $tmpl = &wiki::handleCommonTags( $tmpl, $topic );
        print $tmpl;
        return;
        }
      }

This allows you to add a variable LOCKED on the Web preference page that locks pages and ADMINS that lists the user names of Admins. Of course, the WebPreferences (and probably TWikiPreferences) pages should be locked or else this won't work.

You need to create an adminonly.tmpl file also, of course.

Not throughly tested, BTW.

-- AlWilliams - 09 Sep 2000

On reconsideration, I wonder if:

/(^|,)\s*$userName\s*(,|$)/) 

Wouldn't be better? Didn't try it as the server I was running TWiki on booted me after I accidentally created a loop

-- AlWilliams - 11 Sep 2000

This is a quick solution and certainly workable. One point to consider is user authentication, they can override web preferences. That means a user could create a ADMINS variable on his home page and gain access to the locked topics! That could be prevented with AndreaSterbini's brainstorming idea of SecurityAndVariableOverriding.

I would opt for a more flexibel and scalable solution, AuthenticationBasedOnGroups. This allows you to define several groups which results in a finer granularity of edit permissions.

-- PeterThoeny - 11 Sep 2000

I should have mentioned -- I've also disabled user prefs. It would also be possible to block these special variables when reading user prefs.

In fact, I went ahead and tried that. Here is a summary of the changes (in wiki.pm ).

1. There is one line that calls getPrefsList with $wikiUserName in place. It needs a list of the exclusions:

    getPrefsList($wikiUserName,"LOCKED", "ADMINS" );

2. Then the first line of getPrefsList needs to change:

  my ($theWebTopic, @excludes) = @_;

3. Then every call in getPrefsList to addToPrefsList changes:

   addToPrefsList( $key, $value, @excludes);

I think there are 3 of these.

4. Finally, in addToPrefsList:

sub addToPrefsList
  my ($theKey, $theValue, @excludes) = @_;
  my ($xclude);
  foreach $xclude (@excludes) {
    if ($theKey eq $xclude) {
      return;
      }
    }
// continue on with addToPrefsList

That seems to work. You could use the same idea now to prevent Webs from overriding Site prefs, but I have no need for that. The exclusion list is an array, so you could add topics easily. In fact, if I were distributing this, the list ought to be in wikicfg.pm.

-- AlWilliams - 12 Sep 2000

This works great! Thanks AlWilliams. I wanted global web locks so I added changed the check in edit to

    if (&wiki::getPrefsValue("LOCKED") =~ /(^|(\s+))$topic\s*(,|$)/
      || &wiki::getPrefsValue("LOCKED") =~ /(^|(\s+))\*\s*(,|$)/ ) {
 

So now I can simply say

• Set LOCKED = *

It prevents against creation of new topics in that web also.

-- ManpreetSingh - 14 Sep 2000

    if (&wiki::getPrefsValue("LOCKED") =~ /(^|(\s+))($topic|\*)\s*(,|$)/) {

is the same

-- ManpreetSingh - 16 Sep 2000

AlWilliams' solution is great way of locking pages until we have the AuthenticationBasedOnGroups in place. Until then we can use the code on this topic. I will not take it into the TWiki core to avoid upgrade issues once we have AuthenticationBasedOnGroups in place. However I changed the TopicClassification to FeatureAddOn so that it is listed in the FeatureAddOn topic and can be found as such. Thanks Al for the contribution!

-- PeterThoeny - 17 Sep 2000

---

Works fine for us here, thanks   :-)
I suggest the following user friendly changes to view and index.
In view the Edit-link is changed to an Admin-link.
In index "Admin-only-Topics" are flgged "(Admin)".
A "suitable" template adminonly.tmpl
HowToDo adminonly_edit-index_flag.html
-- KamiloStankiewicz - 11 Oct 2000