Quando provo a estrarre un file da TFS ottengo l'errore TF14098: l'accesso utente negato [nome utente] necessita dell'autorizzazione PendChange per [percorso].Accesso negato su TFS - Permesso PendChange
Ho aggiunto l'utente al gruppo contributore ma ancora non permetterà loro di estrarre un file.
A volte potrebbe essere necessario un po 'di tempo per consentire alle autorizzazioni di eseguire la sincronizzazione.
http://msdn.microsoft.com/en-us/library/ms400712.aspx#doesnottake
Se l'utente (o gruppo di protezione AD) è stato modificato era già noto al sistema, le modifiche dovrebbero essere istantanea. La sincronizzazione entra in gioco solo nello scenario opposto: un gruppo di sicurezza ha già consentito a PendChange di essere autorizzato, quindi un amministratore di Windows ha aggiunto un nuovo utente a quel gruppo. TFS non conoscerà la modifica finché non comunica con la directory attiva durante la successiva sincronizzazione pianificata.
La causa più probabile per ciò che stai vedendo è l'ereditarietà delle autorizzazioni. Anche se l'utente è autorizzato in modo esplicito, qualsiasi ACL di negazione che si applica a lui lo sovrascriverà. Ad esempio, gli ACL impostati su un elemento padre potrebbero essere ereditati. Allo stesso modo, se l'utente è membro di due gruppi (ad es. Collaboratori e lettori), potrebbe avere ACL in conflitto in gioco - e Deny vincerà sempre.
Inoltre, il modello di ereditarietà è stato leggermente modificato nel 2008 SP1. Vedi:
ho sperimentato lo stesso problema quando si uniscono da un ramo bambino ad un ramo genitore. Un membro del gruppo di amministratori di progetto non è stato autorizzato a unirsi a quel ramo.
Dopo aver controllato con "tf perm", assicurarsi che non vi siano permessi Nega per quel ramo per il gruppo.
Dopo aver superato molti luoghi, è stato rilevato che in quel ramo è stato eliminato un checkout attribuito a uno sviluppatore. Trovato utilizzando "Trova nel controllo del codice sorgente" -> Stato "-> Acquista Trova.
Successivamente ha rilevato che uno sviluppatore che aveva accesso a quel ramo aveva tentato di eliminare il ramo (come parte della pulizia) prima di lasciare il Ho annullato tale modifica (utilizzando Annulla selezionando quel checkout) e Presto! Le unioni hanno iniziato a funzionare
Non sono ancora sicuro di come sarebbe potuto accadere e non so una causa. chi ha riscontrato questo problema in una fusione, controlla una volta tutte le casse e se trovi alcuni checkouts (come delete) come strani, annulla e riprova. Questo potrebbe essere un motivo:
Nel mio scenario questo errore è stato corretto quando ero aggiunto al gruppo admin per il progetto.
Nel mio caso questo link qui sotto funzionato bene
"Questo sarà essenzialmente dirvi elenco di tutti gli utenti/gruppi con il loro permesso. Da questo controllo lista se qualsiasi gruppo tu sei il membro è rifiutato per PendChange o negato direttamente per te. In caso affermativo, adottare le misure necessarie per rimuoverlo.
Punto da notare qui è Nega sempre ha la precedenza. Diciamo che sei membro di TFS Admin (dove sono permessi tutti i permessi) e anche Project Reader (dove ad eccezione di PendChange è negato) allora PendChange del lettore avrà la precedenza e non ti sarà permesso di cancellare. "
Aggiornamento:
per TFS 2012 uso "Developer Command Prompt for VS2012" e controllare:. https://msdn.microsoft.com/en-us/library/0dsd05ft(v=vs.100).aspx
questo è frustrante stupido Quindi, se hai questo problema simile, ma non è possibile trovare i permessi effettivi è necessario modificare e non riesco a trovare dove queste autorizzazioni sono impostate tramite l'IDE, è perché è necessario effettivamente accedere alle autorizzazioni facendo clic con il tasto destro del mouse sul progetto e selezionando Avanzate-> Sicurezza, non andando a Team-> Impostazioni progetto team/Impostazioni raccolta progetto team-> Sicurezza. Puoi farlo anche con la linea di comando tf usando i comandi speciali tf di tf, ma ho avuto problemi con questo.
Utilizzando tf perm e TFS ui ho scoperto che il permesso è stato concesso PendChange dando i permessi Gruppo nuovo Checkout specificati alla radice del progetto nella scheda di sicurezza del TFS 2015.
PendChange = Partenza il permesso
In TFS 2017 si chiama "Pend a change in a workspace", che è un nome migliore. – JamesQMurphy
Il permesso dei lettori di essere rimosso dal progetto team in TFS, impedirà la modifica dei file.
L'ho verificato in TFS2013 e funziona correttamente.
Potrebbe anche essere che l'utente non sia mai stato membro di alcun gruppo TFS e la prima volta che si aggiunge un utente a un gruppo TFS che deve sincronizzare? – Ryan
Se si aggiunge un utente direttamente a un gruppo TFS per la prima volta,/dovrebbe/essere istantaneo. Se si aggiunge un gruppo AD precedentemente sconosciuto a un gruppo TFS, ci vorrà del tempo prima che TFS enumeri i membri del gruppo AD e li memorizzi nella cache internamente. –