Why am I not allowed to do this?

Five symptoms, their cause and the way out. Everything here applies to this wiki as it currently runs; the values referred to are in the role matrix.

Your role is shown in three places, depending on what you want to know:

The first two answer “what do I have?”, the third “what am I missing here?”. Only the third puts both figures side by side — and only there, therefore, is the complete explanation.

The panel under every refusal names three things:

If the third row is headed Without signing in, you are not signed in, and the rung named is that of anonymous access — not your account's.

The gap between the second and the third row is the complete explanation. Where it says Required: Edit and This account has: Read, exactly one rung is missing, and the request should name exactly that one.

Any page of this wiki, signed-in account.

Four possibilities, in order of how often they occur:

1. The ACL does not open the area to your groups. The panel then shows a smaller rung under This account has.
2. An account rule sits below the group rule. A rule for your account beats every group rule at the same level, including a lower one. That is deliberate and the usual way of keeping one account out of an otherwise open area.
3. The area requires a session assurance this session has not produced. The panel then names a factor level under Required rather than a permission name. Further under The area asks for a second factor.
4. You are signed in with the wrong account. Two accounts for one person are not unusual, and the panel offers Sign in as somebody else for exactly that.

1. Read the three rows of the panel. They answer the question in full.
2. Take an offered alternative if there is one. It works immediately.
3. Otherwise choose the request control and follow Requesting access to a page or a project.

Namespaces with a factor requirement, plus individual actions in the Vault, the Data Studio, Resources, the Blog and the Azure DevOps components. The complete list is under Actions that require a factor.

Your account's permission is enough; the sign-in is not. Two cases look alike and lead to different places:

The second case cannot be solved alone: enrolling a new factor requires proving the old one. That is exactly why the request is the only exit there — and why it is one of the two kinds that can be raised without signing in.

1. Where Set up a second factor is offered, take it. It takes about two minutes and needs nobody.
2. Otherwise: Requesting a two-factor reset.
3. Check which level is required. Authenticator app (TOTP) is not satisfied by an e-mail code; the level A second factor, of either kind is.

Any closed page.

The panel draws only controls that would actually work. Where the request is missing, one of these four holds:

• You are not signed in, and this kind of request needs a session. Sign in is offered instead — and that is the right next step, because the permission may long since be yours and only the session is missing.
• The daily cap is reached. Your account has raised as many requests as the wiki allows per 24 hours.
• The area cannot be named. Where neither a project nor a repository can be identified, no request is offered — a request about “some namespace” is one nobody can settle.
• The request component is not installed or cannot reach its store. A notice then says that requests cannot currently be recorded, in place of the panel.

1. Sign in where Sign in is offered, and open the page again.
2. With the daily cap reached, wait until the next day, or add to an already open request via My open requests.
3. In every other case give whoever maintains the area the page address you were turned away at. That is the detail from which the rest can be reconstructed.

After a confirmed request.

That is the normal case, not a fault. A request grants nothing; it waits for a person. The confirmation says exactly that and avoids a “Sent!” that would suggest the opposite.

It may additionally be that nobody was notified. Where your request names a project it goes to that project's maintainers; otherwise to the globally configured address, and that may not be set at all. A failed send is logged but not reported as a failure of the request — the record is written all the same, and it, not the e-mail, is the source of truth.

1. Check under My open requests whether your request is in the state open. If it is there, it arrived.
2. After a longer silence, ask whoever maintains the area concerned, giving the request id. It opens the record directly.
3. Do not raise the same request again. A repeat is added to the existing one and speeds nothing up.

A project's navigation rail.

Hubs your project role does not reach are hidden. That is a display decision: it is meant to spare you a row of doors with nothing behind them for you.

Two things follow that are often confused:

• A missing entry does not mean something is hidden there. It means your role does not reach it.
• The hiding is not a boundary. The target page checks its own permission and turns you away with a panel if you open it directly.

1. Open the page directly if you know where the entry led. The refusal then names the required role.
2. Look up under Layer 3: the project role which role opens the area.
3. Request that role: Requesting access to a page or a project.

• Role matrix — what each role allows and does not allow.
• How to: request access — the complete route.
• Roles and permissions — entry point and signpost.