Permissions can be assigned at project level. This works very well. A user can see only the project in which he is involved.
But the user can access the User Page and can see all the other users oft the VSTS account.
Also every user can select all other users from the Azure AD in the identity picker of a WorkItem (no matter if the user is in the same project or not).
A customer user should not know our other customers. Also a external developer should not know our other customers.
Simply put: It is not compatible with data protection laws. So we straight into a legal conflict.

For the identy picker counting the same reasons.
Besides, it is not really intuitive to use if the user sees unknown names.

Also, I think it is not necessary that access to the admin panel exists.
Over the admin panel a user can find a list of teams:
He can draw conclusions on the other projects.

For Stakeholders vsts hides the code tab. That’s why I think that's no big development or?
From our point of view this is a very important step for the tool.

Summarized:
- hide UserHub for non admin users
- hide admin panel for non admin users
- show only users in the identity picker from the project

Use FIPS compliant algorithms if FIPS policy enforcement is enabled on the server. Department of Defense Security Technical Implementation Guides require that FIPS policy is enforced: http://www.stigviewer.com/stig/microsoft_dot_net_framework_4.0/2014-01-08/finding/V-30926

This applies to all US Department of Defense. It is understood that MD5 is much faster and might not even be used for security reasons (i.e. using MD5 to generate a hash to determine file differences on version control check in). However if FIPS is enabled, why not use a FIPS compliant algorithm?

It is much better to experience some degredation in performance when FIPS policy is enabled than to occasionally swallow exceptions and exhibit strange behavior (i.e. mark changes as merged from one branch to another, but not actually take the merge).

with TFS update 3 Test Suite permissions were added which is a good step in the right direction. I would like to see a step further. Separate the Create, Read, Update and Delete Permissions. In my situation i want Feature owners in QA to be able to create their own test suites and add or modify tests, but i do not want them to be able to delete. The deleting of suites or tests within suites needs to be reserved to management. I would like the ability to allow read to groups outside of QA. The Audit helps us trace the changes which is good but i would like to limit the permissions up front.

If the branch policy "Reset code reviewer votes when there are new changes." is set on a branch when a user pushes more changes all code reviewers are reset. The goal here is to not allow unreviewed changes to sneak in with previously review changes.

However, this also has the side effect of resetting users who are blocking the review in a waiting state. For instance, I may have some issue with a code review, so I set my state to waiting. More changes are then pushed which don't address my concerns, this removes my waiting state. Another user then approves the review, which now allows the review to be checked in.

This could be used to internationally, or unintentionally circumvent certain reviewers, which I don't think is the intent of this feature.

service hook

Allow a permission level to assign users to be able to modify the service hooks. We often have user's who currently do not have permission level high enough to edit the service hooks for the project, nor do we want to give them the permission level that is that high. We would like to be able to assign the ability to modify service hooks to users at a lower permission level. Currently there is no permission level we can just toggle to allow these users to be able to add their own service hooks for their projects, thus they have to ask someone with a high permission level just to get notifications of their builds, code check ins etc... into slack

Due to changes made by Microsoft no longer allowing creation of a 'personal/live account' with a custom domain this has impacted any 3rd party suppliers ability to smoothly assist customers on their projects in VSTS.

For VSTS instances from April onward all account used for authentication must be either an official live account (live.com/outlook.co.uk) or a business account which is contained with the Azure Active Directory instance it has been paired with.

The issue is that all VSTS instances for client security ultimately can only be paired with the client tenant or the vendor tenant, both requiring all users who need access to any project in the VSTS account to be added to the relevant domain.

This causes overhead to both customer and client including that an MSDN license used for developers can only be extended to a single alternative account, this means developers cannot have their workload split over multiple client programs/ VSTS instances without purchasing a secondary account.

As in Lifecycle Services Microsoft should allow authentication and pairing to both client and vendor subscriptions (AAD) to remove the overhead the impending change have applied to vendors.

Hi,

This is more of a request than a question. Our developers are using TFS (all have MSDN), but in order for the whole company to adopt TFS we need other departments such as customer support and QA to be able to view, create and edit Work Items.

At the moment you only allow non-TFS users to create new items and view only items they have created. This is extremely limiting and means that we need a massive number of CALS for TFS which cost $499 each. It is a crazy cost for a user only accessing work items. These users do not want to use the source control, or build server but just to be able to view what bugs/tasks exist for a product and see the statistics.

Please could you consider for TFS 2012 a better licensing model as you are constraining the deployment of TFS which does not make sense. Could you either allow non-TFS users to view and edit all work items or sell a new type of TFS CAL with restrictions which is not $499 but more like $100.

Doing this would mean more companies to use TFS throughout the company and not restrict it just to the developer community.