none
TFS 2017 Update 1 - Behavior change for DEFAULT rule

    Question

  • There appears to be a behavioral change in how DEFAULT works when applied to a field definition in TFS 2017. The documentation seems to indicate this is a change compared to previous versions as well. But this change seems to make DEFAULT with a field useless now.

    We have a custom field called Adjusted on our stories. In the past we have applied a DEFAULT rule that copies the value from Story Points into this field when the work item is saved, if the field is not yet set. Starting with VS 2017 this doesn't work anymore. Based upon the documentation, the UI may choose either the previous or current value of the field. If it chooses the previous value then this makes setting a default value for a field based upon another field pretty much useless. The only way to get the default value to work properly would be to have the user change the source field and save it and then make some other change such that Save button becomes enabled and, assuming the target field is empty, the target field will pick up the field value when saved.

    The other options for defaulting a field don't seem to apply to the specific case where you want field A to follow field B's value when field B is set and field A is not yet set.  DEFAULT does a check for empty but is otherwise equivalent to COPY. So using COPY with an ALLOWEXISTINGVALUE wouldn't work. ALLOWEXISTINGVALUE doesn't really mention that it works in the context of a copy/default. SERVERDEFAULT doesn't allow the user to change the value at all so cannot be used for fields that are editable by the user. So at this point I'm really curious how we can set a field to match another field but still allow either field to be set to some value during the same save operation?

    I've considered using a WHEN condition to wrap the SERVERDEFAULT call but this seems a little much given that DEFAULT used to work just fine.

    Michael Taylor
    http://www.michaeltaylorp3.net

    Tuesday, March 14, 2017 6:24 PM

Answers

  • Hi CoolDadTx,

    Yes, it's copy the previous value of that field. About your require, the COPY and Default both are not suitable. And I also tested it TFS 2015, get the same result. And I tried to use many WHEN rules with SUGGESTVALES, because the SUGGESTEDVALUES allow other values but those values in suggest list. But this also not that perfect.

    Here a user voice I submitted for you to vote about the workitem rules to allow it copy from other values and also accept to change to other values: https://visualstudio.uservoice.com/forums/330519-team-services/suggestions/18641788-add-a-workitem-rule-to-allow-copy-current-value-fr

    TFS Product Team is listening to your voice there.

    Thanks for your understanding.

    Best regards


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, March 17, 2017 2:09 AM
    Moderator

All replies

  • Hi,

    Thank you for posting here.

    >>how we can set a field to match another field but still allow either field to be set to some value during the same save operation

    The best choice is using COPY rule, but just like you said, the copy rule doesn't allow the value you set, it always copy the value from the other field. And the DEFAULT rule only copy the value from the other field the first time, the next time, it doesn't change again.

    Maybe you could use the WHENCHANGED rule:

     <FIELD name="Adjusted" refname="test.Adjusted" type="Double" reportable="measure">
            <WHENCHANGED field="Microsoft.VSTS.Scheduling.StoryPoints">
              <COPY from="field" field="Microsoft.VSTS.Scheduling.StoryPoints" />
            </WHENCHANGED>
     </FIELD>
    Best regards

    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, March 15, 2017 8:15 AM
    Moderator
  • I could try that but I'd use a WHENNOT empty. But COPY and DEFAULT are defined in the same documentation and therefore have the same notes. I'm curious to know if this was a breaking change to DEFAULT, why COPY wasn't also impacted and/or there is something wrong with my template.
    Wednesday, March 15, 2017 2:14 PM
  • The same behavior occurs with COPY. It seems to be using the value when the item was opened. Unfortunately a WHENCHANGED is not sufficient. I don't want to change a field whenever another field changes. I only want to change it when it is empty.

    It is my humble opinion that COPY and DEFAULT are broken in 2017. I don't see any benefit in these rules when applied to copying fields if there can be no guarantee that changing the source field will allow the changed value to be used in the rule. It isn't a realistic situation to expect users to know there is a default/copy rule on a field and to save changes to the source field so that the target field updates. Even worse is that they will still need to make some change in item because Save doesn't get enabled until the user explicitly makes a change in the form.

    Wednesday, March 15, 2017 7:14 PM
  • I tried the rule you recommended and it has the same problem. Copying still gets the original value, not the current value. So I think I'm stuck at this point.
    Wednesday, March 15, 2017 7:52 PM
  • Hi CoolDadTx,

    Yes, it's copy the previous value of that field. About your require, the COPY and Default both are not suitable. And I also tested it TFS 2015, get the same result. And I tried to use many WHEN rules with SUGGESTVALES, because the SUGGESTEDVALUES allow other values but those values in suggest list. But this also not that perfect.

    Here a user voice I submitted for you to vote about the workitem rules to allow it copy from other values and also accept to change to other values: https://visualstudio.uservoice.com/forums/330519-team-services/suggestions/18641788-add-a-workitem-rule-to-allow-copy-current-value-fr

    TFS Product Team is listening to your voice there.

    Thanks for your understanding.

    Best regards


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, March 17, 2017 2:09 AM
    Moderator
  • And I also tested it TFS 2015, get the same result

    I don't see how this could have been the same way in 2015.  We've been using this rule in tfs 2015 for quite a while and it worked exactly as I explained it. When we set the story points for a story during sprint planning and saved the changes then our charts that looked at the adjusted field updated to reflect the fact that the default field was being set. Additionally, when looking at the results of a query the adjusted field was showing as set even though it doesn't do that until I select the item in tfs 2017. 

    We still have our original tfs 2015 database copy that I can restore to confirm the behavior we were seeing in 2015. My suspicion is that it has something to do with the new Web layout stuff but I'll have to switch back to it to verify.

    Friday, March 17, 2017 2:44 AM
  • Hi CoolDadTx,

    If you get any result after go back to TFS 2015, please post them here. 

    Because in my TFS 2015 Update 3, I add the Default rule in a custom workitem type to copy values from story points. I got the same result in TFS 2017. If you success, could you please share your xml file here. And I will check in the query and I will post my result back soon.


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, March 20, 2017 2:39 AM
    Moderator
  • I went back to our TFS 2015 instance and I'm seeing the same behavior that you mentioned. The UI shows the value correctly but adding a query or chart that pulls the underlying value doesn't work until the work item is saved at least one more time. It's odd that we never noticed this issue in the past as we use these queries all the time. It must be that our work items were being updated fast enough that we never noticed.

    Nevertheless this makes DEFAULT pretty much useless and COPY almost useless for doing anything with fields that are changing. Having the UI update to make it look like they are set when they aren't doesn't help matters. Hopefully the UserVoice item will be popular enough to fix.

    Thanks for helping to sort this out.

    Monday, March 20, 2017 3:33 PM
  • Hi CoolDadTx,

    Thanks for coming back and let use know your result.

    Best regards


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Tuesday, March 21, 2017 2:56 AM
    Moderator