We have group of developers, Testers & BA's who will work for more that 30 projects under collection, so instead of adding them for each project want to create security groups at collection level so everyone will have access to all the projects under collection.
On TFS, we want to have customized groups like Developers, Testers, BA's at collection level so they will have access to all the projects so that I don't need to add them for each project.
So instead of adding them for each project want to create security groups at collection level so everyone will have access to all the projects under collection? So how can I do that!!!
You can try to add the new customized groups as members of the "Project Collection Administrators" group. This will grant access to all projects in the collection, including the futures ones.
Related
I have almost 400 projects to create in my TFS project collection in TFS 2017. I don't want to have to create and configure each project, one at a time. I'd like to create a custom process template, which seems easy enough to do, but I can't find how to add an AD group to the Project Administrators group.
The GroupsandPermissions.xml file allows the creation of new groups but doesn't accept the Project Administrators group as an option. I've read here where others have tested it. Also the macro for project administrators is reported not to work because the group already exists.
Any ideas how to add an AD group to project administrators in the process template or otherwise?
We are trying VERY hard to come up with a method to apply security to all of our projects without having to add to each project individually. We have 1300 projects to migrate from other source control to hosted projects on VisualStudio.com.
How do you recommend adding security groups at the collection level to control 1300+ projects using inheritance.
Any pointers?
In TFS/VSTS there are different levels or group/permission settings:
Server-level (TFS)
Collection-level
Project-level
(object-level) eg:Build ...
Refer to Permissions and groups in VSTS and TFS for details.
You need to set them based on your requirements accordingly to make the system working as expected. That means you have to set them separately and for each team project individually. We cannot achieve that by simply set it only on Collection Level.
Default permissions and access for VSTS and TFS for your reference.
However in VSTS we can crate groups (eg: Developers, Testers ...) and add users to the groups accordingly, also can add them to multiple projects during adding the users:
Manage Settings(gear icon) --> Users --> Add new users --> Enter the user eamil address --> select Access level --> Projects --> Add all --> set other options ... --> Add
I have a TFS 2010 Work Item Type with a custom field called "Requested By." This field can be populated with any name, but since most of the requests come from project developers throughout the organization, the SUGGESTEDVALUES property should populate the dropdown list with members of any TFS team project.
I have tried various values for SUGGESTEDVALUES, but both Collection\ Project Collection Valid Users and Server\ Team Foundation Valid Users seem to return every valid Active Directory account—well over 10,000 names.
I recognize that one option is to add an ALLOWEDVALUES item with multiple LISTITEM entries for Project\ Contributors for every team project, but with more than 150 team projects in the organization, this would be time-consuming initially and challenging to manage in the future.
Is there any easy way to populate the drop-down with TFS valid users who have actually been assigned to any team project in the collection, and exclude "Valid" users who exist in Active Directory but have never been assigned to a project?
What do you get if you use Project Collection Valid Users?
Project Collection Valid Users is the correct group to use, and I have entered it correctly.
However, one project team wanted to make their code available to the entire organization, and added ORG\Domain Users to the [Project]\Readers group. This was discovered by running a full audit with TFS Projects based on a hunch that something like that must have happened.
Having answered this question with "because a project team was doin' it wrong," I have posted a follow-up question to find out how to correctly grant all valid TFS users access to a specific project. See How can I grant Team Project access to all Project Collection Users? for the discussion on (hopefully) doing this "the right way."
I'm new to Team Foundation Server 2010 and I have a question about permissions.
Is it possible for a project to inherit permissions from a project collection? I want to setup a custom contributor group at the project collection level and add the developers to it. Each time they create a new project I want to inherit the permissions from the project collection. That means I don't have to explicitly add the developers to the project each time they create one.
Maybe there is some other way of doing this and not having to setup a custom contributors group? Any help would be appreciated!
I would recommend setting up some Active Directory Groups along the lines of:
TFS Contributors
TFS Administrators
TFS Project Managers
(You could also do this for specific projects. You get the idea.)
Give these AD groups the permissions you need, and simply add/remove the developers to the AD groups. If you can get the ability to manage the AD group, this will be much simpler that administering through the TFS admin tools.
Hopefully, you'll already have AD groups that fit these needs, saving you the trouble. Maybe a team-wide distribution list, for example?
You can create collection level roles (TFS Groups) and edit your process template to grant permissions to those roles so there are set by default in every new project.
Can you prevent a user with project admin or project collection admin rights from updating a project's work item definition or its project template?
Basically we have a TFS instance with multiple projects and project collections. We want to ensure we have one template and work item definition across all of them so any updates should happen across all project\project collections.
thanks
p.s. we do this since we are interfacing with another system and if a new, required field is added it will cause issues.
Members of the "Project Collection Administrators" and "Project Administrators" group have hard-coded admin permissions. Even if you remove the "Edit Project-Level Information" permissions, they have the ability to give that permission to themselves again.
The only way to prevent members of these groups from modifying the work item definitions, is to remove them from the group. Some people create a new administrators group and give them the same permissions, except for the permission to modify work item types.