How can we improve Visual Studio Team Services (VSTS)?

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.

50 votes
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)

    We’ll send you updates on this idea

    elaf shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    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.

    Ewald Hofman

    5 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Chris Holl commented  ·   ·  Flag as inappropriate

        I looked in the blog link and didn't see this requested feature in the list. What is the status? I added a vote for this because when I set the policy "Require associated work items" I want it to mean REQUIRE. This is critical in certain business, such as FDA. If some want it optional then provide a setting to say Optional or Required. (We're using TFS 2017.)

      • Alex Jamrozek commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        @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  ·   ·  Flag as inappropriate

        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.

      • teyde commented  ·   ·  Flag as inappropriate

        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.

      Feedback and Knowledge Base