Quickstart: raise the first administrative request and settle it

The shortest way from “the plugin is installed” to “a request is in the administrator's inbox and has been decided there”. Four steps, about ten minutes. You need two sessions: an ordinary account and an administrator account.

• wkrequest, wkcore and wkstorage are installed and enabled. Without storage the wiki records no request and says so — Requests are not possible here.
• Two browsers or two profiles, so both sessions can be open at once.
• A namespace the ordinary account may not read.

As the administrator: Admin → Access Control (/doku.php?do=admin&page=acl). Deny read on a namespace to the ordinary account, for example projects:payroll.

Create projects:payroll:start with a line of text, so there is something real behind the denial.

In the ordinary session, open projects:payroll:start.

Under DokuWiki's usual denial banner there is now a panel headed What you can do now, offering Request access, Sign in with another account, My open requests and Back to the wiki. Nothing was configured for it: the panel hangs on a single event and therefore appears on every denied page in this wiki.

Choose Request access. Three things are worth a look before you fill anything in:

• What will be sent with this request is open by default and lists every field that will be stored — including the line Context source: observed by this wiki.
• The security note is not boilerplate: passwords, one-time codes, recovery codes and access tokens do not belong in this form, are stripped before storage, and nobody in administration will ask for them.
• The closing sentence says what a request is not: Sending this request does not change anything by itself.

Write a sentence or two into Why do you need this? and choose Send request.

In the administrator session: Admin → Administrative requests, directly /doku.php?do=admin&page=wkrequest. The menu entry carries the number waiting.

The list opens on Still waiting rather than on everything — an inbox opening on a year of settled requests buries the three that need an answer.

Open the request. You get the facts, the justification and two blocks: Where this is settled — with the link to the surface that actually performs the change — and Decision.

Follow the link, set the read permission in access control, come back and choose Completed with a note such as read granted on projects:payroll.

• In the ordinary session projects:payroll:start now opens.
• The request stands in the inbox as Completed; the history shows Raised and Status changed with actor and timestamp.
• Counter-check against duplicates: raise the same request a second time before step 4. The confirmation then reads Added to your open request — no second row appears, your new wording is appended to the existing one.
• Counter-check on finality: look in the completed request for a way to reopen it. There is none; Completed is terminal, and the screen says so instead of showing an empty control area.

• The case the whole plugin was built for: sign out completely and use Reset password on the sign-in screen. If the account holds an authenticator, the screen offers Request a two-factor reset beside it. A request raised that way carries a red unverified marker in the inbox — the user name in it is only a claim. Establish who is really asking before acting.
• wkidentity — the flows that case hangs on.
• wkrequest (German) — the package page: the seven request types, the six states, the security boundary.