Role matrix

The complete account of what each role in this wiki allows and what it does not, layer by layer. This page is the one source for permission values; every other page links here rather than restating them.

The layers are asked in this order, and each may only refuse. A role on layer 3 cannot grant what layer 1 has denied.

The base ladder. It applies to every page and every namespace and is the only layer that works without any component of this house.

DokuWiki evaluates the most specific rule, not the highest. In order:

1. A rule for this account on this page.
2. A rule for a group of this account on this page — where several apply, the highest wins.
3. The same two steps in the next namespace up, all the way to the root.
4. Nothing matches: no access.

An account rule beats every group rule at the same level, even a lower one. That is how a single account is kept out of an area its group has open.

This layer does not ask who you are but how well this one session has shown it. It is the most common reason for being signed in and turned away all the same.

A requirement is bound to a scope. Eight kinds exist:

• namespace — every page under a prefix.
• plugin, module, view — a component, a module within it, a single view.
• command, adminAction — a command, or an administrative action.
• group, user — bound to the requester rather than to the target: “this group always needs TOTP”.

Where several apply, the highest holds. A session that has proved MAIL_OTP satisfies MFA_ANY and MAIL_OTP, but not TOTP.

email_users can only add a method, never take one away. A missing or unreadable policy file can therefore never lock anybody out.

Inside a project a ladder of its own applies. It decides which hubs appear in the navigation and who may change a project's membership.

The group overlay first, then the ACL. First match wins:

1. Superuser → admin.
2. Member of @dwdo_<project>_maintainers → maintainer.
3. Member of @dwdo_<project>_contributors → contributor.
4. Member of @dwdo_<project>_readers → reader.
5. Otherwise: translate the ACL value on the project root — from 16 → maintainer, from 2 → contributor, from 1 → reader, else none.

The prefix dwdo_ is configurable (roleprefix). The role is always determined at the project root, never at the page you happen to be viewing — it is a property of the project, not of the request.

Hubs your role does not reach are hidden from the navigation rail. That is a display decision, not a boundary: the target page checks its own permission. A missing menu entry therefore means “there is nothing here for you”, not “something is hidden here”.

Some components additionally run a ladder of their own, because their subject is not a wiki page.

Four rungs of one ladder, expressed in the same numbers as layer 1 — so there is no second permission store, only one ACL line per group on the mount point.

New mount points come with four presets:

team is the only tier whose groups depend on the project. It is the right choice as soon as several closed projects sit side by side: the other three know only “nobody”, “everybody signed in” and “everybody”.

A capability matrix rather than a ladder, because the six capabilities really are independent.

Resolution, first match wins:

1. Superuser → always allowed.
2. With dbadmin_readonly at 1, write and design are refused — even where the matrix grants them.
3. A rule for the connection beats a global one; within one scope an account rule beats every group rule. Group rules at the same scope are unioned.
4. No matching rule → refused.

Several components additionally require a session assurance per layer 2 for individual actions, whatever permission the account holds.

A project's membership screen is the only one that needs no global administration. That is why it is the destination an access request about a project is routed to — see Where a request goes.

Your own component hangs its refusal on the same infrastructure instead of writing a sentence of its own. Two calls are enough.

A refusal about a missing permission:

$req = plugin_load('helper', 'wkrequest');
if (is_object($req) && method_exists($req, 'accessPanel')) {
    echo $req->accessPanel([
        'resourceLabel' => $title,
        'required'      => $req->permissionLabel(AUTH_READ),
        'current'       => $req->currentPermissionLabel($pageId),
        'draft'         => [
            'type'     => 'ACCESS_REQUEST',
            'owner'    => 'myplugin',
            'handler'  => 'myplugin:settings',
            'resource' => $pageId,
        ],
        'alternatives'  => [['label' => $otherRoute, 'href' => $url]],
    ]);
}

A refusal about a missing second factor:

echo $req->stepUpPanel([
    'requirement' => 'MFA_ANY',
    'origin'      => 'myplugin:delete',
    'back'        => $backUrl,
]);

Sign-in, “my open requests” and the way back are appended without the call site having to remember them; each reports itself unavailable in the situation it does not fit and is then left out.

So that a request reaches the right place, the component registers its administrative screen:

$controller->register_hook('WKREQUEST_REGISTER_HANDLERS', 'BEFORE', $this, 'registerRequestHandlers');
// ...
$event->data['handlers'][] = [
    'owner' => 'myplugin',
    'id'    => 'settings',
    'label' => $this->getLang('menu'),
    'url'   => wl('', ['do' => 'admin', 'page' => 'myplugin'], true, '&'),
    'types' => ['ACCESS_REQUEST', 'ADMIN_ACTION_REQUEST'],
];

Where a component knows the closed area better than the core does, it sharpens the panel instead of drawing a second one beside it:

$controller->register_hook('WKREQUEST_REFINE_DENIED', 'BEFORE', $this, 'refineDeniedRequest');

$event->data then carries id, resourceLabel, required, current, facts, alternatives and draft. Returned values are taken back one by one; an unusable value is discarded and the generic answer stands.

Places where the model today does less than the rest of this page suggests. They are listed because a gap nobody names looks like a mistake by the reader.

• Roles and permissions — entry point and signpost.
• How to: request access — the route from refusal to request.
• Why am I not allowed to do this? — symptoms and their causes.