Feature Proposal: Limit the creation of sub webs separately

Motivation

We would like to get tighter control over who is allowed to create subwebs. Allowing it to all users with the right to edit is to broad.

Description and Documentation

Not everybody with rights to edit, ALLOWCHANGE, should be allowed to create a subwebs.

Examples

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

A nice thing would be to have a Setting like ALLOW/DENYWEBCREATE.

-- Contributors: AndreLichtsteiner - 18 Feb 2010

Discussion

I agree. I encountered a site recently where subwebs have to be specifically excluded, because of problems in some old plugins, but the install needed to be able to read existing subwebs.

It's really easy to add new permissions classes, so this isn't difficult to do. However it has to be very carefully documented. Ths proposal will not be complete with (1) details of how the new access mode works and (2) details of the documentation required.

-- CrawfordCurrie - 18 Feb 2010

Crawford has an important point.

I see in our silly content management system a very advanced 10000 access rights features, and the result is that things are so complicated that no normal user understands it.

The beauty of Foswiki is that access rights are pretty simple. There are things you cannot do. But people can hide confidencial information and limit it to people and groups. And you can limit who can edit things that are "easy to screw up" or has to be protected for business reasons.

The minute you add more rules you add possible combinations of rules. And the permutations increase exponentially. Getting access rights from NerdoMeter score 4 to 9 takes very little effort. And you can never go back once it is out of the box and in a release.

So think carefully.

We not only need a spec for the feature itself but also how it interacts with all the combinations of the existing features. And we need the documentation written that explains how this works. And for access rules I would like to see it in the right context. Ie the entire access rule docu written up.

Personally I find adding access rules that allows creating webs but not subwebs is sponteneously nonsense. Why? Maybe Crawfords special example is a case but it does not justify a feature. Same problem can be solved by a simple business rule that you communicate.

I can much more see admins that want to limit the number of root webs but will allow as many subwebs as people like. That is how I administrate. I use a plugin that only shows subwebs of the current root web in the left bar. I try to limit the WebLeftBar web list to something people can overview. Each department has a web. But the departments are OK to add subwebs to divide some of the heavy applications with many topics from each other. So that is the feature where I see a need to have different rules for creation webs and subwebs. So have this in mind also when you write up the spec.

Keep it simple.

Keep the interactions with other ALLOW and DENY setting minimal.

Do not limit it to your special usecase because it is a bit unusual and mysterious and uncommon.

-- KennethLavrsen - 18 Feb 2010

I agree, the access control mechanism is not simple, but at least it is clear when it comes to handling access to topics:

to view

ALLOW/DENY...VIEW

to create and edit

ALLOW/DENY...CHANGE

to rename and delete

ALLOW/DENY...RENAME

All those definitions can be done on a TOPIC topic level or inherit the per WEB definition.

But when it comes to handling webs, the system differs between rootwebs and subwebs:

Subwebs

Subwebs are treated as topics of the according parent web and therefore CHANGE and RENAME of the parent web apply. The rights to view are defined in the Subweb it self, or inherit from parent web if not defined. But be aware, that by default VIEW rights are set in WebPreferences.

Rootwebs

An additional access right is introduced

• create, rename and delete: ALLOW/DENYROOTCHANGE

What I would like to have is the following:

create, rename and delete webs on all levels

ALLOWWEBMANAGE and DENYWEBMANAGE (or alike)

• This applies to Subwebs when set in the WebPreferences of a web
• Applies to to Rootwebs if defined in SitePreferences.

As I see it, ALLOW/DENYWEBMANAGE in SitePreferences would be equal to ALLOW/DENYROOTCHANGE and can therefore be treated as an alias. Like this, it wouldn't break any existing installation.

-- AndreLichtsteiner - 19 Feb 2010

I did some first trials to get a patch providing this functionality:

/lib/Foswiki/UI/Manage.pm

@@ -126,3 +126,3 @@
     }
-    Foswiki::UI::checkAccess( $session, $parent, undef, 'CHANGE',
+    Foswiki::UI::checkAccess( $session, $parent, undef, 'MANAGE',
         $session->{user} );
@@ -611,3 +611,3 @@
     # web - stop here
-    Foswiki::UI::checkAccess( $session, $oldWeb, undef, 'RENAME',
+    Foswiki::UI::checkAccess( $session, $oldWeb, undef, 'MANAGE',
         $session->{user} );

Now, the system should base the rights creating or moving a web based on Variables called ALLOWWEBMANAGE and DENYWEBMANAGE as well as ALLOWROOTMANAGE and DENYROOTMANAGE.

Tests on Foswiki 1.0.9 look promising.

-- AndreLichtsteiner - 24 Feb 2010