Is there any way to remove the ability for members of the Project Administrator group from being able to modify the Work Item Type Definitions in their projects?
If I were to create a custom group that mimics project administrators (contains the sames permissions), which permission or permissions would need to be denied?
Thanks for your help!
This may help:
Manage process template permission
Users who have this permission can download, create, edit, and upload process templates to the team project collection.
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 using tfs 2013 update 4.
One of our colleagues downloaded TFS PowerTools by itself and started to edit workflow and fields of our projects.
Is there any way to deny this functional for him?
Hi is not a project administrator, not TFS adminstrator. TFS powertools allows to change witd for all who can see the project.
Set his Manage Process Template permission to Deny. This is a collection-level setting.
They must have higher level permissions than you think. Maybe an AD group they are a member of has been added in to Collection Admins or something like that?
Customize a process template
"To download or upload process templates, you must either be a member
of the Project Collection Administrators group, or your Manage process
template permission must be set to Allow"
Download the sidekicks utility and you'll easily be able to see which permissions the user has.
Team Foundation Sidekicks
If they are a member of Project Admin, Collection Admin or Server Admin then remove them or explicitly deny the "manage process template" permission
I have a custom group in TFS, and I would like to grant access to this group for every team project so we don't have to do this one by one.
It seems like the developers have access via Source Control Explorer, but cannot see these projects via 'Connect to Team Project'.
Any idea what is going wrong, or what permission is missing?
We are using TFS2012 on-premise.
The tfssecurity command line tool allows us to manage permissions for TFS groups and users. We could use it in a PowerShell script to grant access to projects that already exists. However I haven't found a way to use this command at the TFS collection level in order to grant permissions for future projects.
The approach I use is based on the fact that TFS permissions are inherited unless explicitly denied.
To create an user group that will automatically access all existent projects as well as the futures ones, follow those steps:
Create a new security group at the project collection level. From Visual Studio you can do it from the "Team / Team Project Collection Settings/Group Membership" menu. On TFS Online you can access to "Account Settings / Security" page.
Add the new group as a member of the "Project Collection Administrators" group. This will grant access to all projects in the collection, including the futures ones.
Deny the permissions of the new group, in order to limit the administrator permissions inherited by the group. You can use an existent TFS group as template, and deny all permissions except those explicity allowed to the group which behavior you want to copy. For example, if you want to create a group with the same permissions that has the default "Project Collection Valid Users" group, you can deny all permisisons except "Create a workspace", "View build resources" and "View collection-level information"
It is possible but you’ll need to give your users a log more privileges than they need to have. You can give them privileges that are similar to project collection administrators and they will have access to all projects but with elevated privileges.
It is possible do this but only for source control like you’ve already done but I’m not really sure about connecting to projects, working with workitems and such.
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.