TWiki/UI/Manage.pm contains the following:

    # check permission, user authorized to create webs?
#    TWiki::UI::checkAccess( $session, $webName, $topicName,
#                            'MANAGE', $session->{user} );
    #hack due to late realisation of hacking possibility

This means that WEBMANAGE is useless. This requires a proper fix, either in the code, or in the doc which describes WEBMANAGE.

CC

The complexity here comes from hierarchical wbs. MANAGE is just not useful any more. The ability to create a web needs to be deetrmined by examining the access to the containing web. For example, if a user wants to create Projects.Wheel.Bicycle, then CHANGE on Projects.Wheel should determine their rights.

Just for a moment, let's disregard the distinction between WEB and TOPIC ACLs, and focus on the meaning of CHANGE. If I am changing a topic, I need CHANGE permission on the topic. If I am creating a new topic, or creating a subweb, I need CHANGE permission on the containing web. If I am creating a root web, I need CHANGE permission on some yet-to-be-invented root level (call it ROOT). Currently we have no way of expressing the permissions on this superweb level. Historically, this is what MANAGE did, but it is really obscure.

Since MANAGE has effectively disappeared, I don't propose re-implementing it; let's take the opportunity to do something a bit more consistent and intention-revealing. Taking the levels WEB and TOPIC, it seems natural to add ROOT as a third level.

So I propose that the permissions evaluation order change as follows (changes italicised):

1. If the user is a super-user
   • access is PERMITTED.
2. If web and topic are defined and DENYTOPIC is set to a list of wikinames
   • people in the list will be DENIED.
3. If web and topic are defined and DENYTOPIC is set to empty (i.e. Set DENYTOPIC =)
   • access is PERMITTED i.e no-one is denied access to this topic
4. If web and topic are defined and ALLOWTOPIC is set
   1. people in the list are PERMITTED
   2. everyone else is DENIED
      • Note that this means that setting ALLOWTOPIC to empty denies access to everyone except admins (unless DENYTOPIC is also set to empty, as described above)
5. If web is defined and DENYWEB is set to a list of wikinames
   • people in the list are DENIED access
6. If web is defined and ALLOWWEB is set to a list of wikinames
   • people in the list will be PERMITTED
   • everyone else will be DENIED
     • Note that setting ALLOWWEB to empty denies access to everyone except admins
7. If web is not defined and DENYROOT is set to a list of wikinames
   • people in the list are DENIED access
8. If web is not defined and ALLOWROOT is set to a list of wikinames
   • people in the list will be PERMITTED access
   • everyone else will be DENIED access
9. If you got this far, access is PERMITTED

The call in Manage.pm would become

    # check permission, user authorized to create web here?
    my $parent = undef; # default is root if no parent web
    if( $webName =~ m|^(.*)[./](.*?)$| ) {
        $parent = $1;
    }
    TWiki::UI::checkAccess( $session, $parent, undef,
                            'CHANGE', $session->{user} );

Note that this requires careful examinataion of all existing calls to checkAccess to ensure consistency with the "undef topic means web access" and "undef web means root" rules. This examination is long overdue anyway.

CC

Exhausting, but at least it's done.

CC

Updated headline for release notes

KJL

4.1.0 released

KJL