Frustrated with the WIT Rules Engine?


I use TFS to manage my software projects. The software projects are to develop TFS, which gets kind of wierd :-)


But there are many things I’d like to do with the WIT Rules engine, that I can’t. Like



  • You can’t mark at task as Closed, unless you have Remaining Hours set to zero.

  • You can’t mark a bug as closed, unless all dependent bugs are also marked closed (same with tasks)

  • If you mark a bug a duplicate of another bug, you must link to that bug.

These are just a few. (I could go on and on)


We are looking into how we can make the rules engine more extensible and flexible. But I want to make sure it meets your needs.


So, let me know … what is that that YOU want to do with the rules engine, but can’t?


Comments (12)

  1. Jeff Lynch says:

    Gregg,

    I’d recommend making the WIT "rules" TFS admin configurable on a project by project basis in Rosario. This will allow the TFS admin to customize the rules to fit the development team’s (or development manager’s) work style for each project. Every dev team I’ve worked with (developing or managing) has worked differently and no pre-configured set of WIT rules seems to exactly fit.

    Jeff Lynch

  2. Sean.McLellan says:

    Any chance of seeing workflow (WF) be part of TFS?

  3. teke175 says:

    Adding diferent access control for different work item states. For example if you create an approval work item it can be edited up until the time it is marked as approved.

  4. stefan_sp says:

    Gregg,

    things I’d like to see in a future version:

    – custom form layouts for different user groups, e.g. our support team should only see support related fields

    – New linktype: Links to child workitems. The work for our scenrios is done in several (child) development tasks. It should be possible to define a rule to prevent a workitem of being set to resolved if one of the child items is not resolved. I kow you already said that, but it is my main requirement for the rules engine.

    – automatically set a workitem to resolved if all child workitems are resolved.

    – The possibility to make controls invisible based on a rule.

    Regards,

    Stefan

  5. Sometimes I feel a little like I’m sitting at an information desk in a mall directing people to what

  6. RSS It All says:

    Sometimes I feel a little like I'm sitting at an information desk in a mall directing people to what

  7. Gregg Boer says:

    These are great comments. Thanks for taking the time. Please keep them coming.

  8. Willy-Peter Schaub on Light Weight Scrum Process Template vs. Conchango and TFS/VSTS and working offline‚Ķfallacy,…

  9. paso says:

    It’s always dangerous to ask questions like this, because it may become a long list. So here it goes.

    Some of them are not really ‘rule engine’ related but I saw a similar request from Dan Kershaw so I put them all together)

    I took a real life example to illustrate some of my requests.

    Example:

    Priority field is set by combination of Frequency and Severity fields.

    Testers can only enter those 2 fields and should not see the derived Priority value.

    Program Managers however should be able to see and change these values.

    The following field definition SHOULD make sure that an ordinary user can not set the priority when entering a work item.

    I say SHOULD because I noticed that this allows a user to set the Priority field to ANY value, even invalid ones. It seems that the ALLOWEDVALUES list is NOT checked because it is only valid for Program Managers.

    –> REQUEST: HIDE field rule (this is different from READONLY. Read-Only can not be used because then the value can not be set automatically because SERVERDEFAULT is not allowed for the "value" and "field" from-types.

    –> REQUEST: SERVERDEFAULT for from-types "value" and "field"

         <FIELD name="Priority" refname="Company.Common.Priority" type="String" reportable="dimension">

    <!– Intial value is set automatically at submit time (see Workflow|Transitions|"" to "New" )–>

    <!– In all other states the value is set to READONLY except for Program Managers –>

           <HELPTEXT>Priority for the project.</HELPTEXT>

           <ALLOWEXISTINGVALUE />

    <ALLOWEDVALUES for="[Project]Program Managers" >

             <LISTITEM value="P1: Urgent" />

             <LISTITEM value="P2: High" />

             <LISTITEM value="P3: Medium" />

             <LISTITEM value="P4: Low" />

           </ALLOWEDVALUES>  

    The following state definition allows Program Managers to change the Priority when switching state.

    Requires a lot of typing (and manage difficulties) when you have a lot of states.

    If another group, different from Program Managers, should also need permissions to change priority in this state, then you have to create a new group because multiple groups are not allowed for "not’ and ‘for’. This makes management of groups unnecessary complicated.

    –> REQUEST: reuse of conditions between states

    –> REQUEST: multiple values for the Conditional Field Rule Attributes ‘not’ and ‘for’

           <STATE value="Accepted" >

     <FIELDS>

       <FIELD refname="Company.Common.Priority" >

                 <READONLY not="[Project]Program Managers" />

       </FIELD>

     </FIELDS>

    </STATE>

    The following transition definition makes sure that the Priority field is set according to the entered Severity value.

           <TRANSITION from="" to="New" for="[global]Team Foundation Valid Users">

     <FIELDS>

       <FIELD refname="Company.Common.Priority" >

                 <WHEN field="Company.Defect.Severity" value="Blocking" >

                   <COPY from="value" value="P1: Urgent" />

                 </WHEN>

                 <WHEN field="Company.Defect.Severity" value="Critical" >

                   <COPY from="value" value="P2: High" />

                 </WHEN>

                 <WHEN field="Company.Defect.Severity" value="Inconvenience" >

                   <COPY from="value" value="P3: Medium" />

                 </WHEN>

                 <WHEN field="Company.Defect.Severity" value="Cosmetic" >

                   <COPY from="value" value="P4: Low" />

                 </WHEN>

       </FIELD>

     </FIELDS>

    What I realy would like to do is make this Priority field dependent on Severity and Frequency. For that I need a matrix like dependency, but I can not do this.

    Frequency    Always Frequent Intermittent Rare

    Severity

    Blocking   P1 P2 P2  P2

    Non-functioning P1      P2      P2        P3

    Irritating              P2      P2      P3        P4

    Cosmetic                P3      P3      P4        P4

    REQUEST: define multi-field dependencies (one child with more than 1 parent)

  10. paso says:

    PART2

    One of my biggest frustrations: the COPY rule

    Great rule but it should only be set ONCE and not changed without the user noticing it every time the work item is opened. With the current implementation you have no option to change the value of the field after it has been set. It looks like you can change it, but as soon as you re-open the workitem to set another field, the ‘rule engine’ will silently change all fields with a COPY rule to their default values. Even without informing the user about this change.

    (http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=740470&SiteID=1)

    Because the REASON can only be changed when the STATE changed, we have implemented a lot of STATES to get more detail.

    E.g.: developers can set the state to ‘resolved’ meaning that the defect has been fixed but not yet tested. They can also set the state to ‘tested’ meaning that the defect has been fixed and tested. For both transitions it should be possible to associate a workitem when checking in the changeset.

    Another thing with these actions is that you cannot define the default behavior. As soon as the check-in action is defined, the ‘Resolved’ value is displayed by default when doing a check-in, while most of the times, one just ones to associate the check-in with a specific work item.

           <TRANSITION from="Accepted" to="Resolved" >

             <ACTIONS>

               <ACTION value="Microsoft.VSTS.Actions.Checkin" />

             </ACTIONS >

           </TRANSITION>        

           <TRANSITION from="Accepted" to="Tested" >

     <ACTIONS>

               <ACTION value="Microsoft.VSTS.Actions.Checkin" />

             </ACTIONS >

           </TRANSITION>        

    REQUEST: same action (e.g.: checkin-in) for more than one state transition

    REQUEST: allow to define default check-in action.

    Multi user list in query definitions that use the ‘in’-operator.

    Now you can only select one of the users and have to enter all others by typing their exact names. It would make things a lot less error prone when you would be able to select additional users from the drop down list.

    User specific templates

    When entering a lot of defects, some fields may be identical for all work items. It would be great if a user could save a work items as some kind of template to be used the next time he or she creates a new work item. This would save him the trouble of setting identical fields for each new work item.

  11. stefan_sp says:

    Gregg,

    one more thing:

    I’d like to have a transition rule which only fires depending on a field value.

    E.g.:

    We have a custom workitem field. For the transition from active to resolved it should be "required" but only if the reason is "fixed". If the bug is deffered it should not be required.

    Another example: we have an extra field "blocked reason". This should be required if you set the issue field to yes.

    regards,

    Stefan

  12. Gregg Boer says:

    This is amazing information. Lots of it we already knew about, but it adds such clarity to have examples. Thanks!