Introduction to Microsoft Team Foundation Server Options

codeling 1263 - 5394
@2020-02-12 23:09:14

Permission Inheritance

Some permissions are managed through a hierarchy. Within this hierarchy, permissions can be inherited from the parent or overridden. Security groups assign a set of permissions to those members of the group. For example, members of the Contributors group or Project Administrators group are assigned the permissions that are set as Allowed to those groups.

If a permission isn't directly allowed or denied for a user, then it may be inherited in two ways.

  • Users inherit permissions from the groups to which they belong. When a permission is allowed for a user directly or through membership in a group that has that permission, and it is denied, either directly or through group membership, the permission is denied.

  • Object-level permissions that are assigned for nodes of a hierarchy - areas, iterations, version control folders, work item query folders - are inherited down the hierarchy. That is, a user's permissions that are set at area-1 are inherited by area-1/sub-area-1, if the same permission is not explicitly allowed or denied for area-1/sub-area-1. If a permission is set explicitly for an object, like area-1/sub-area-1, then the parent node is not inherited, regardless of whether it is denied or allowed. If it's not set, then the permissions for that node are inherited from the closest ancestor that has the permission explicitly set.

When permission is Not set for a user or group, the user or group can be affected by the explicit state for the permission for groups to which they belong because permissions in TFS are inherited. For example, when you review the permissions for a user or group, you might see both Allow and Inherited allow set for permissions. The latter permission is inherited from some other group the user or group belongs to. In this example, a user might belong to a group at the project level and a group at the collection level in a project. If one of those groups has a permission that is explicitly set to Allow and the other group has the same permission Not set, the user will have the Inherited allow permission to perform the actions that are controlled by that permission. The user inherits permissions from both groups, and the Allow permission takes precedence over the Not set permission. 

To understand why a permission is inherited, you can pause over the permission setting, and then choose Why?. A new window will open. It displays the inheritance information for that permission.

Some object-level Security dialog boxes provide an Inheritance on/off option. Use this option to disable inheritance for folders, shared queries, and other objects. 

 


codeling 1263 - 5394
@2020-02-12 23:40:07

Do's and Don'ts when assigning permissions

Do's:

Use Windows groups when managing lots of users.

Consider granting the Contribute permissions to users or groups that require the ability to create and share work item queries for the project.

When adding many teams, consider creating a Team Administrators group to TFS where you allocate a subset of the permissions available to Project Administrators.

When adding teams, consider what permissions you want to assign to team leads, scrum masters, and other team members who may need to create and modify area paths, iteration paths, and queries.

Dont's:

Don't add accounts to the Readers group that you've added to the Project Administrators group. Doing so causes a Deny state to be assigned to several permissions.

Don't change the default assignments made to a valid users group. If you remove or set the View instance-level information permission to Deny for one of the Valid Users groups, no users in the group will be able to access the team project, collection, or deployment, depending on the group you set.

Don't assign permissions that are noted as 'Assign only to service accounts' to user accounts. 


codeling 1263 - 5394
@2020-02-18 09:06:54

You grant permissions to users based on the tasks they perform in TFS. In general, you'll want to grant the minimum set of permissions users need to do their job. You can use the following default groups and their associated permissions to manage most users and meet their needs.

Users

Team Foundation Server

SharePoint Foundation or SharePoint Server

SQL Server Reporting Services

Add accounts for people who need view-only access to the project.

Readers

Visitors

Browser

Add accounts for people who contribute to or manage the development of the software project.

Contributors

Members

Browser

Add accounts for people who manage user access to the project or need to configure or customize the project.

Project Administrators

Owners

Team Foundation Content Manager

When you add user accounts to your team, they're automatically added to the Contributor group. They then have access to most of the features they'll need to contribute to code, work tracking, builds, and test. However, the Contributor group doesn't allow users to create shared queries or to add area or iteration paths. You have to grant these permissions separately. Contributors in project-level are granted the following default permissions.


codeling 1263 - 5394
@2020-02-18 11:10:35

You can't change the permission settings for the Project Administrators group or the Project Collection Administrators group, which is by design. However, for all other groups, you can change the permissions.

Users browsing this topic
Guest