Disallow TFS checkin policy override
The ability to override checkin policies is in some cases absolutely unwanted. If I use policies I have fairly reasons to do them and dont't want it can be overridden...
'No override allowed' will be much more useful than generate a list of overridden policies and will help enforce code quality.
As explained in this blog post (http://blogs.msdn.com/b/visualstudioalm/archive/2015/10/08/how-we-use-user-voice-to-make-a-better-product.aspx), we had updated the status of this suggestion to “Under Review” to let you know we are tracking it on our backlog. To better indicate which one we are actively working on or which ones are on our 6-month plan, we introduced the states “Started” and “Planned”. The goal is to give an update on in progress suggestions at least every 3 months. This suggestion is still on our backlog, but they are not part of the 6-month plan.
Alex Jamrozek commented
I'd like to see this tied a permission set in the TFS user profile data. By TFS user group or individual. A lead/architect may need this ability, while day-to-day programmers need more restrictive oversight.
Paul Coste commented
@Teyde it should be up to the customer to make that determination. While I agree in some cases, it really depends on the policy. If I write a custom policy and apply it to a custom path and say that in all cases, check-ins must comply with that policy, and the policy requires that certain static analysis is performed, or some field is filled out, etc. for regulatory compliance purposes, then it is an overstep for Microsoft to say that this is not a valid business case. Let the customer make that call based on their needs.
Steve St Jean commented
All check-in policy overrides are audited and there is also an alert email that you can subscribe to. I would suggest subscribing to the alert email and then dealing with the overriding devs as a training/HR issue rather than using technology to enforce compliance.
There are always emergencies and precluding an override could get very expensive in those cases.
Maybe it will enforce code quality, but I really don't believe it. The check-in process has little to do with the code itself. ****** code is still ******, even after all the policies are met. I would counter-argue, and say that when I need to override, I have a very good reason indeed to do so. It's usually when the process is counter productive.