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.
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
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
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)
If a user has access to multiple security groups, does TFS take the highest level group, or the lowest level group for access rights?
For example, if user John, belongs to the Read Group (can only read the source control but not edit) and then is added to the Developer Group (can read and edit source control) which group does TFS recognize?
Since he belongs to both groups can he still only Read since that is the lowest level or can he now edit since he is also part of the Developer Group and that is the highest level?
Permissions
It combines the permissions from all the users groups.
If the user is denied access to anything they still can't access it even if they are given access to it elsewhere.
If the user is given access to something in any group they will have access to it (unless of course something else denies them).
If there's no explicit allow or deny in any of the users groups, they will be denied access.
Access Levels
Access levels are done separately from group permissions - access can be set to limited, standard or full in the tfs 2012 admin area.
For TFS 2010 the only group that acted a bit weirdly was the work item only group, which afaik acted as a explicit deny on everything but editing your own work items. This functionality is replaced with access levels in tfs 2012.
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