搞了几天的TFS2010权限的设置，学习了这些与大家分享下：

1、TFS权限介绍

Team Foundation Server 权限设置分为显式授权和隐式授权，显示授权是设置：“拒绝”和“允许”。 隐式授权，它既不将权限设置为“允许”，也不将权限设置为“拒绝”。 此授权是一种隐式“拒绝”设置，又称为“未设置”。

2、权限设置要理解的4个重要概念

2.1 拒绝

“拒绝”不允许授权用户或组执行权限说明中提到的操作。“拒绝”是TFS中最强大的权限设置。 如果用户所属的TFS组将特定权限设置为“拒绝”，那么即使用户所属的另一个组将该权限设置为“允许”，该用户仍无法执行该功能。 此规则的唯一例外是用户属于项目的“Project Administrators (项目管理员)”组的、团队项目集合的“Project Collection Administrators”组或Team Foundation Administrators”组。 如果用户属于项目的 Project Administrators 组，则该组的权限会覆盖该用户在项目中的显式“拒绝”。 同样，如果用户属于项目的 Project Collection Administrators 组，则该组的权限会覆盖该用户在该集合中的显式“拒绝”。 如果用户属于 Team Foundation Administrators 组，则该组的权限会覆盖该用户在 Team Foundation Server 中的显式“拒绝”。

2.2 允许

“允许”则允许授权用户或组执行权限说明中提到的操作。 “允许”是 TFS中第二强大的权限设置，最常使用。 如果不将权限显式设置为“允许”，用户或组将不能在TFS中执行该操作。

2.3 未设置

默认情况下，TFS中的多数权限既没有设置为“拒绝”，也没有设置为“允许”。 权限处于“未设置”状态，它隐式拒绝授权用户和组执行权限说明中指定的操作。 但是，因为权限既没有显式设置为“拒绝”，也没有显式设置为“允许”，它可以从用户或组所属的其他组继承授权。

ps：默认新建活新添加的用户对于权限的操作都是“未设置”。

2.4 继承

当用户或组的权限为“未设置”时，由于TFS中的权限是可继承的，所以用户或组可能受到其所属组权限的显式设置的影响。 例如，用户可能属于一个项目中的两个自定义组。 如果其中一个组的某个权限显式设置为“拒绝”，另一个组的同一权限未设置，则该用户将无权执行此权限所控制的操作。 该用户从两个组中继承权限，“拒绝”权限优先于未设置的权限。

ps: 某些授权设置优先于其他授权设置。 在 TFS 中，“拒绝”权限优先于包括“允许”在内的所有其他权限设置（对于该显式结构）。 如果“拒绝”权限是从层次结构父元素（如版本控制）继承的，则不优先。 例如，用户可能属于一个项目中的两个组。 对于其中一个组，“发布测试结果”权限设置为“拒绝”；而另一个组则将该权限设置为“允许”。 “拒绝”设置优先级更高，用户无权发布测试结果。规则的唯一例外是从层次结构父元素继承显式“拒绝”或者用户属于下列组之一：

Project Administrators

Project Collection Administrators

Team Foundation Administrators

在层次结构（如版本控制和工作项跟踪）中，在特定对象上设置的显式权限会覆盖从父对象继承的显式权限

ps：在正式授权设置之前可阅读msdn资料：Team Foundation Server 默认组、权限和角色。

http://msdn.microsoft.com/zh-cn/library/ms253077.aspx

3、版本控制权限：

默认情况下，下列各组处于版本控制级别：（多于两个单词的组名称全部简写。示例：Team Foundation 全部简写为TF，Team Foundation Server 简写为TFS，ProjectName简写为PN， Project Administrator 简写为PA，Team Foundation Administrator 简写为TFA，Team Project Collection Name 简写为TPCN以此类推为组英文名称的每个首字母大写组合）

项目级别： PN/PA PN/Contributors PN/Readers PN/Builders

项目集合级别： TPCN/PCA TPCN/PCSA TPCN/PCBSA

自定义的项目集合组，或者项目可以赋予想要的版本控制权限。

版本控制权限表

TFS2010 团队项目集合级别权限下，新建一个组1，并为自定义的组1设置版本控制权限，和团队项目级别权限下新建一个组2，并为自定义的组2设置版本控制权限和安全性的项目级别权限，然后将组1加入组2中，那么两个不同级别组1和组2的版本控制权限谁的优先级高?

这个问题是我提出的，我实践测试结果：

遵循微软的权限设置策略，拒绝权限最高，下来是允许权限，最后是未设置。举例可以这样分析，为组1设置“锁定”权限为“允许”，这样组1中的所有用户都具有“锁定”的权限，将组1（团队项目集合级别的组）加入组2（团队项目级别的组），为组2设置版本控制权限，假如“锁定”权限设为“允许”，那么组一种的所有用户都具有锁定权限，假如将组2中的“锁定”权限设置为“拒绝”那么组1中的所有用户就失去了锁定的权限，假如将组2的“锁定”权限设置为“未设置”，那么组1的用户还是具有锁定的权限。(以上说明被各种管理员组的成员的权限覆盖掉了)，还有一种情况是假如开始组1中的“锁定”权限就设置为“拒绝”，组1加入组2之后，组2的“锁定”权限设置为“允许”，组1中的用户还是会具有锁定权限。我理解的是一种就近原则吧！至少还没有碰见不符合这个的。如果有人打破这条麻烦告诉我一声。

这个前提是组2的团队项目级别“安全性”里项目权限要将“查看项目级别信息”设为“允许”。

利用vs2010与具有管理员权限的账户在客户端设置团队项目用户版本控制权限

打开vs2010直接点击— 链接到Team Foundation Server 或者在“团队”—— 链接到Team Foundation Server

ps：在团队菜单下可以进行多个操作。

“链接到Team Foundation Server 服务器 ”后 ，团队资源管理器会自动打开。然后进行你想要的设置。

ps：双击团队资源管理器下的树形菜单中的“源代码管理”，可打开“源代码资源管理器”

团队资源管理器

团队项目集合节点

团队项目集合设置---组成员资格 这一栏下可添加自定义的组，并添加成员，新建的组默认属于Project Collection Valid Users

团队项目集合设置---安全性 这一栏设置对团队项目集合的权限，默认属于Project Collection Valid Users这个组的具有访问项目集合的权限。

团队项目节点

团队项目设置---组成员资格 这一栏可添加自定义组，并添加成员，新建的组默认属于Project Collection Valid Users。

团队项目设置---安全性 这一栏设置对团队项目的权限，添加自定义的组并设置对于当前团队项目的权限，然后自定义组的成员就可以依照响应权限访问到当前项目。一般仅仅赋予“查看项目级别信息”就可访问到项目。

源代码管理资源管理器

团队项目集合节点

属性---安全性 这一栏可添加、设置自定义组对团队项目集合下的团队项目的项目源代码的操作权限。（这一步的设置针对的是团队项目集合设置——组成员资格下添加的自定义组的权限，对于团队项目集合下的团队项目，只要将设置好的组加入就可适用。）

团队项目节点

属性--安全性 这一栏可添加、设置自定义组对团队项目集合下的团队项目的项目源代码的操作权限。（这一步的设置针对项目团队项目设置——组成成员资格下添加的自定义组的权限，适用于当前项目。）

重要：

源代码管理中，对于团队项目集合级别的组，要适用于某一个团队项目集合下的项目，需要将这个组加入需要适用的团队项目下“团队项目设置”中添加的赋予了访问或者更高级别团队项目权限的自定义组。当然也可以不用新建将其加入默认组。

默认属于Project Collection Valid Users组的组或者用户具有访问TFS服务器下的团队项目集合的权限。