How to: request access

You are standing in front of an area your account may not open, and the permission is not something you can give yourself.

On every closed page a panel sits beneath the refusal listing what you can do now. If it carries a control named after the request — Request access, Request a role, Request repository access, Request a two-factor reset — the whole route is one form.

What the form brings with it has already been filled in by the page: what this is about, which permission was missing, which screen can answer the request. You only add the reason.

1. Stay on the page that turned you away. Do not open the form elsewhere: the context is taken from the refusing page and is otherwise lost.
2. Check the rows Required and This account has in the panel. If the area named there is not what you were trying to reach, you are on the wrong page.
3. If an alternative is listed — another route, a read-only view, the project page — take it first. It works immediately.
4. Otherwise choose the request control.
5. Under Why do you need this? write a sentence that makes the decision possible: what you are working on, who knows about it. “Please unlock” is not a reason and only lengthens the route.
6. Send. You receive a request id.

If you have asked for the same thing before and that request is still open, your reason is added to the existing one instead of a second being filed.

This route applies when your account has a second factor that you can no longer produce — a lost device, a deleted app.

1. Open the page that turned you away. If it offers Set up a second factor, your factor is not lost but was never enrolled: take that route, it takes two minutes and needs nobody.
2. Otherwise choose Request a two-factor reset.
3. If you are not signed in, enter the account name this is about and an e-mail address for the reply.
4. Send.

While you are signed in, My open requests in the same panel leads to your list. You can also withdraw a request of your own there.

Without a session there is no list. A request raised without signing in cannot be withdrawn either — otherwise anybody could cancel another person's lockout request.

For whoever maintains an area.

1. Open the inbox via ?do=admin → Admin requests, or via the counter on the workbench rail.
2. Open a row. It carries the requester, the item concerned, the reason, and the context the refusing page passed along.
3. Check the Identity row. Where it says claimed rather than verified, first establish who is asking, by some means other than the request.
4. Follow the linked screen. There — and only there — you carry out the change. The inbox itself changes no permission.
5. Come back and set the request's state. A note on the decision saves the next person a reconstruction.

The inbox sends you to the screen that can actually answer the request, not to a general one.

Where the recorded screen no longer answers anything — because the component was removed, say — the inbox offers no shortcut rather than pointing at a wrong screen.

• The context is redacted. Anything that looks like a secret — one-time codes, passwords, tokens — is stripped before storage. Do not rely on it: enter nothing secret.
• There is a daily cap. An account may raise a limited number of requests per 24 hours. Once it is reached the form says so and stores nothing.
• Two kinds are possible without a session, because they describe exactly the situation in which one cannot sign in: two-factor reset and account help. Everything else needs a session.
• A failed notification is not a failed request. The record is written by the time the confirmation appears; the e-mail is only a prompt.

• Why am I not allowed to do this? — when no control appears.
• Role matrix — what the requested role allows.
• Roles and permissions — entry point and signpost.