My organization wants to use TFS to track user sign-off of work items by changing the work item Status. The first user I asked to view a work item in TFS is being prevented from viewing the work item. How do I set permissions for him to view and edit the work item status?
I suggest you to access your Web Portal of project, select Security section ensure that your user have permission, exist in Contributors Group that contains permission. (Best practise is to set contributor group to your members team)
Related
My TFS installation in on premise and I would like to add users to a project allowing them to create and edit work items, but not work as a developer who can create branches or check in code. Is there a default group like that?
I do not see anything in the permission list that mentions code rights.
That's exactly what the stakeholder access level is for. Access levels are different from security groups. Stakeholders don't even have the ability to see the Code tab.
I've got a TFS server in which team projects exists. These team projects have area paths below them. These area paths represents projects of certain customers. We want to give customers access to their area path.
The problem is when we do that they automatically gain access to all other area paths withing that team project. Is there a way of limiting access so the customers can only see their area path and nothing else?
No such a feature to limit users in team project level with the area path set.
Area path only restricts the users on work items:
Area paths allow you to group work items by team, product, or feature
area. Whereas, iteration paths allow you to group work into sprints,
milestones, or other event-specific or time-related period. Both these
fields allow you to define a hierarchy of paths.
Please see About area and iteration paths (aka sprints) for details.
So, if you don't want to the users see the specific team projects, then you just need to remove the users from the related TFS groups.
If you just want to restrict the users on manage the sources/files or source control on specific Repository/branches, then you can create teams or groups and set the permission accordingly. Please see below articles for details:
Add teams and team members
Permissions and groups in VSTS and TFS
As mentioned in this thread, by design a team can access other teams backlogs and work items.
To deny different teams access to other teams work items I used a workaround which might work for you as well.
The workaround is to use TFS security groups to limit teams access to area paths. By default, every team is created as a member of the default security group [project]\Contributors which gives the team access to all area paths.
Here are the steps I followed:
Create a new security group for every team
Make the new groups members of the Contributors default group
Add every team as a member of its new respective security group
Remove all teams from the Contributors group
In the project's areas admin screen, open each area's context menu and click the security option (check this article)
In the security view, add the newly created security groups
For each group, allow/deny the permissions based on your requirements
Please note, this workaround will not hide other area paths from the users in the not allowed groups. They still can navigate to backlogs of other groups but they will not view or edit the work items. This behavior is same for reports and dashboards as well
I am using TFS 2015. I make one user as Readers in project settings but still the user is able to create and update work-items/bugs. So, I am confused what I need to do in order to allow a user to just view the work-items/quires/stories but not add/edit any item.
The Readers group setting does not restrict ability to edit or create work items. You can do that in area path security settings Set permissions and access for work tracking. So you may create new group (in example Disallow Access Group). Then open security setting for the root area.
Deny needed permissions
In your case you have to enable View work items in this node
If you have the user only in the Readers TFS group of the given team project, the user will not be able to able to add/edit work items.
This can happen if you have altered the group membership, so that Readers are member of the Team (the team created by default or a new team), which is default a member of Contributors. This way readers TFS Group get inherited from Contributors permissions.
Verify the Readers group has below as permissions (default)
and it is not something like below
The other possibility is your user has collection level permissions so the project permissions are inherited to allow by default.
We have a situation where TFS was taken into use when we all had 2 user accounts. We started using TFS with account A but, after a while, found out that account B was better. In the end we want to use the A accounts only for RDP sessions. We would now like to remove all the A accounts from TFS so that we don't make mistakes in assigning tasks to a person.
Deleting the old accounts from the AD is not an option, we still use those accounts for RDP sessions. What we did was migrate all the WI's from account A to account B. Thereafter I removed all permissions for the old A accounts, with in mind that TFS would clear those accounts since they are no longer in use. The double account in the assigned-to field
Unfortunately the old accounts are still visible despite they are no longer involved in any project or group. No rights for the (development) user
How can we remove those accounts from TFS? Maybe there is somekind of cache that needs to be cleared somewhere, or a rebuild of the warehouse?
Thanks in advance!
By Default the Assigned To field shows the list of all Valid TFS Users (this is a specific TFS Group). So if you don't want somebody to show up in that list you have to make sure they are not in the Valid TFS Users group. If you inspect this group in the TFS Admin interface you can see which other groups are members of it. Now it's just a matter of tracing through the many TFS security groups to make sure that those user accounts are not included anywhere that would result in them being part of TFS Valid Users.
In SharePoint, I want users to add items but not be able to edit or delete them after. The "add item" permission shows "edit" not checked (i.e. so they should not be able to edit) However, they can. Any suggestions?
Are you testing as a site collection admin? they ignore permissions
SharePoint works on a highest permissions policy so if a user is in 2 groups which have permissions to the list and one group can edit but the other group cannot, they will get the edit permissions from the first group.
I would suggest double checking the permissions on the list and (as djeeg mentions in his answer) make sure you are not testing as the Site Collection Administrator as they have complete/full permissions to everywhere in the site collection regardless of what permissions you set the user in People and Groups.