In our company, only users with a Project Amin role can update the Iteration Capacity in TFS. Is there a setting we can add to a Contributor role to allow each individual to update their own Capacity for a given Iteration? We do not want to give everyone Admin role as they can change everything on the site, but need every individual to go update their own capacity and add their vacation days ahead of the sprint planning session.
Actually users in your team do not need full Project Admin role to update Iteration Capacity.
You could simply follow below prerequisites:
You must connect to a team project. If you don't have a team project yet, create one in TFS/VSTS.
You must be a member of the Contributors group or be granted Stakeholder access to add or modify work items. Or, you must have
your View work items in this node, and your Edit work items in this
node permissions set to Allow.
If you haven't been added to a team project or team, get added now.
As you can see, you just need to assign the users in contributors group or modify work item in this node permission to allow. More details please take a look at this tutorial-- Set your team's capacity, the same for Iteration.
Related
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.
Background
I'm working on implementing Agile permissions along with Code permissions for a TFS project. There will be multiple teams in this project, we currently have 3 but will grow. I am set up with Project Admin rights.
Area Permissions
At the root TFS Area Project Admins have the ability to create, delete and edit this node rights. Team members do not.
Problem
When I add my self to one of the teams groups I'm no longer able to delete items from this node even though I am a Project Admin. That means I can never be a part of the teams? This will hurt me in capacity planning amongst other areas where I work on tasks when not administrating the project.
Am I missing something? Is there a setting to allow Most Privileged or something that allows me to be a team member and still perform administration of the project?
Don't use explicit Deny permissions -- an explicit Deny overrides explicit Allows. "Not Set" is what you're looking to use -- that means "deny, unless otherwise allowed".
The problem is that "Deny" will override any other permissions. Deny always wins.
you can do 2 things
Remove ADMIN from the team group. An admin account shouldn't need to
be a member of a contributors group as admin is a superset of the
permissions given to contributors.
If for some reason you cannot remove the account from this group then
change the permissions. TFS permissions have 3 states. Allow, not set, Deny.
As the deny is causing the issue, then change the
permissions to "not set" this will still prevent members of the
contributors group from being able to manage permissions, but will
stop overriding the admin users permissions
I use TFS 2013 with one team collection and I have a Project.
This project uses area paths to differentiate between teams.
So I have an area Path/Team lets call it "Inventing".
This Inventing team has a Product Owner who should only do what a product owner is supposed to do in scrum.
I can add this particular person to the area path and allow him the rights.
I want to say: he is the product owner of this AreaPath.
Do I need to create for every area path a TFS Group called "product owner inventing" and add/remove the persons for that TFS Group?
Or is there a better solution?
There is no way you can isolate a specific user role like this from the create wizard by default. So yes, you'll need to create a group for the product owner. Remember that work items have links to change sets, so it might be hard to isolate the product owner completely from viewing any code it's not a simple checkbox to tick.
BTW we often do trust external people with the code they're basically owner of. Non Disclosure Agreements and contracts can get a long way in legally closing that loop. I'd expect that the product owner will look over the shoulder of team members, will have opportunity once in a while to access developer workstations, no matter how hard you secure everything. Trust is important in Scrum and Agile, this is one aspect of trust.
I am having a little difficulty understanding when a person should configure JIRA permissions using groups and when they should use project roles. I have read the online documentation, however, the difference between the two seems subtle.
A group seems simple enough. Group users into a named bucket. Assign the group to one or more permissions within a permission scheme to enable access to functionality for any users within the group. Assign the permission scheme to a project to apply the permissions to that project.
A project role seems very similar. It does all of the above except that you can also add groups to project roles. It seems that a project role also allows a project administrator to add their own users to a project instead of requiring a system administrator.
However, I am not sure how I can leverage this. Here is an example of what I want to achieve.
Have multiple projects created in JIRA.
All of our managers, developers, etc. have the same permissions across all projects.
Our clients have access only to their projects.
I think that the best way to accomplish this is to:
Create an employees group to which I add all of our employees.
Create one or more project roles to which I add the appropriate clients.
Assign permissions to the Default Permissions Scheme using the employees group.
Copy the Default Permission Scheme to a new project specific scheme, e.g., client-scheme
Assign the client-scheme to the client specific project.
However, it seems that I am not leveraging project role membership. How does this come into play?
What is the best practice for using JIRA groups and project roles? What is the different between the two?
We are advising to work with roles as it has a couple of advantages
a. You can setup the complete configuration based on roles.
For instance you might have a workflow transition 'validated' which can only be executed by someone who is a tester.
You have the choice to add a transition condition 'user is in group tester' or 'user has the role tester'.
If you are working in an organisation where users have different roles in different projects, choosing the first transition condition (user is in group tester) will not work (or you would need a new workflow for each project)
The same applies for notifications.
You can configure a notification on the 'issue resolved' event, specifying that the 'users in group tester' get notified or 'users who have the role tester'.
When using roles, adding someone to a project is very simple - just check what role the person has in the project, add them in the project configuration (view members) and you are done. He will have the right permissions, get the right notifications ...
b. Configuration
When you use roles for configuration, you don't need system administration rights to add someone to a project. The project lead will be able to add the user. No need to bother the system admin.
Looking at your description, I would have
A project role 'employee'
A project role 'customer'
A group 'employees'
configure the project role such that the group employees is a default member of the project role employee
This way you can use the same permission scheme for all projects. When adding a new project, you just need to add the client specific userid to the client role.
When a new employee start, you add him to the employees group.
The day that you have a specific, ultra secret project, where only a couple of employees need to have access, you can remove the group 'employees' from the role 'employee' and add the specific users to the role.
Hope this helps
Francis
Historically, JIRA had groups first. Then roles came along and are the recommended way to control authorization in most cases.
~Matt
Groups are global. Roles can be thought of as per-project (local) groups.
Roles are much better: else with a large number of projects you quickly end up with a proliferation of Groups and permission schemes (one per project).
You lose nothing by using role-based permission schemes, since you can add a Group to a role.
But you gain a lot of flexibility. Eg you'd currently have the Employee role be filled with your Employees group for every project, but as your company and complexity grows, you can have different Employees per project, without having to change the permission schemes