Perché non mi è consentito?

Cinque sintomi, la loro causa e la via d'uscita. Tutto quanto segue vale per questo wiki nella versione in esercizio; i valori richiamati si trovano nella matrice dei ruoli.

Il vostro ruolo compare in tre punti, a seconda di che cosa volete sapere:

I primi due rispondono a «che cosa possiedo?», il terzo a «che cosa mi manca qui?». Solo il terzo affianca i due dati — e solo lì, quindi, si trova la motivazione completa.

Il pannello sotto ogni rifiuto indica tre cose:

Se la terza riga è intitolata Senza autenticazione, non siete autenticati e il gradino indicato è quello dell'accesso anonimo, non quello del vostro account.

La distanza fra la seconda e la terza riga è la motivazione completa. Se vi si legge Richiesto: Modifica e Questo account ha: Lettura, manca esattamente un gradino, e la richiesta dovrebbe nominare esattamente quello.

Qualsiasi pagina di questo wiki, account autenticato.

Quattro possibilità, in ordine di frequenza:

1. L'ACL non apre l'area ai vostri gruppi. Il pannello mostra allora un gradino più basso sotto Questo account ha.
2. Una regola d'account sta sotto la regola di gruppo. Una regola per il vostro account batte ogni regola di gruppo dello stesso livello, anche una più bassa. È voluto ed è la via consueta per tenere un singolo account fuori da un'area per il resto aperta.
3. L'area richiede una garanzia di sessione che questa sessione non ha prodotto. Il pannello indica allora sotto Richiesto un grado di fattore anziché il nome di un permesso. Oltre, sotto L'area richiede un secondo fattore.
4. Siete autenticati con l'account sbagliato. Due account per la stessa persona non sono insoliti, e il pannello offre Accedi come qualcun altro proprio per questo.

1. Leggete le tre righe del pannello. Rispondono integralmente alla domanda.
2. Percorrete un'alternativa offerta, se ve n'è una. Ha effetto immediato.
3. Altrimenti scegliete il comando della richiesta e seguite Richiedere l'accesso a una pagina o a un progetto.

Namespace con obbligo di fattore, oltre a singole azioni in Cassaforte, Data Studio, Risorse, Blog e nei componenti Azure DevOps. L'elenco completo è sotto Azioni con obbligo di fattore.

Il permesso del vostro account basta; l'autenticazione no. Due casi si assomigliano e portano in luoghi diversi:

Il secondo caso non è risolvibile da soli: configurare un nuovo fattore presuppone dimostrare quello vecchio. Proprio per questo la richiesta è lì l'unica uscita — e per questo è uno dei due tipi presentabili senza autenticazione.

1. Se vi compare Configura un secondo fattore, percorrete quella via. Richiede circa due minuti e non coinvolge nessuno.
2. Altrimenti: Richiedere un azzeramento del secondo fattore.
3. Verificate quale grado è richiesto. Applicazione di autenticazione (TOTP) non è soddisfatto da un codice via e-mail; il grado Un secondo fattore, di qualunque tipo sì.

Qualsiasi pagina chiusa.

Il pannello disegna soltanto comandi che avrebbero effetto. Se la richiesta manca, vale uno di questi quattro motivi:

• Non siete autenticati e questo tipo di richiesta presuppone una sessione. Compare allora Accedi — ed è il passo giusto, perché il permesso potrebbe essere già vostro e mancare soltanto la sessione.
• Il limite giornaliero è raggiunto. Il vostro account ha presentato tante richieste quante il wiki ne consente ogni 24 ore.
• L'area non è nominabile. Se non è riconducibile né a un progetto né a un repository, non viene offerta alcuna richiesta: una richiesta su «un namespace qualsiasi» non è evadibile da nessuno.
• Il componente delle richieste non è installato o non raggiunge la propria memoria. Compare allora, al posto del pannello, l'avviso che al momento le richieste non possono essere registrate.

1. Autenticatevi se viene offerto Accedi, e riaprite la pagina.
2. Con il limite giornaliero raggiunto, attendete il giorno successivo oppure integrate una richiesta già aperta tramite Le mie richieste aperte.
3. In tutti gli altri casi indicate a chi cura l'area l'indirizzo della pagina su cui siete stati respinti. È il dato da cui si ricostruisce il resto.

Dopo una richiesta confermata.

È il caso normale, non un errore. Una richiesta non concede permessi; attende una persona. La conferma dice esattamente questo ed evita un «Inviato!» che lascerebbe intendere il contrario.

Può inoltre essere che non sia stato avvisato nessuno. Se la vostra richiesta nomina un progetto, va ai suoi manutentori; altrimenti all'indirizzo configurato globalmente, che potrebbe non essere impostato affatto. Un invio fallito viene registrato ma non segnalato come errore della richiesta — la registrazione è comunque scritta, ed è essa, non l'e-mail, la fonte della verità.

1. Verificate sotto Le mie richieste aperte se la vostra richiesta è nello stato aperta. Se compare lì, è arrivata.
2. Se il silenzio si prolunga, rivolgetevi a chi cura l'area interessata indicando il numero di richiesta. Con esso la registrazione si apre direttamente.
3. Non ripresentate la stessa richiesta. Una ripetizione viene aggiunta a quella esistente e non accelera nulla.

La barra di navigazione di un progetto.

Le aree di lavoro che il vostro ruolo di progetto non raggiunge vengono nascoste. È una decisione di presentazione: deve risparmiarvi una fila di porte dietro le quali per voi non c'è nulla.

Ne discendono due cose che spesso si confondono:

• Una voce sparita non significa che lì sia nascosto qualcosa. Significa che il vostro ruolo non basta.
• Il nascondere non è una protezione. La pagina di destinazione verifica da sé il proprio permesso e vi respinge con un pannello se la aprite direttamente.

1. Aprite la pagina direttamente, se sapete dove conduceva la voce. Il rifiuto indica allora il ruolo richiesto.
2. Consultate sotto Livello 3: il ruolo di progetto quale ruolo apre l'area.
3. Richiedete quel ruolo: Richiedere l'accesso a una pagina o a un progetto.

• Matrice dei ruoli — che cosa ogni ruolo consente e non consente.
• How to: richiedere l'accesso — il percorso completo.
• Ruoli e permessi — ingresso e indicazioni.