locked
How to change properties of a WIT field in different ways based on different transition Reasons. Is this possible? RRS feed

  • Question

  • When moving a custom work item type from NEW to CLOSED I need to enable the following situation:

    If the reason Resolved is chosen, Request Lead needs to be enabled and required

    If any other reason besides Resolved is chosen,  Request Lead should be read only (disabled)

     

    I tried going into the transition from New to Closed and added a when rule on Request Lead, so that if the reason of Resolved is selected, Request Lead is readonly. I cannot add another field rule for the same field to handle the enabled and required if the reason is something else, not that I can see anyway. Man would it be nice if I could…  So scrapped that.

     

    Then I tried making the default state of Request Lead in the field definition disabled when state = Closed, figuring I would override that on the transition to Closed by changing the field state to Required when Resolved is chosen from the Reasons dropdown (using a WHEN rule on reason), but required does not override disabled, so it is ONLY disabled.

     

    I also tried making the default state of Request Lead in the field definition Required when state = Closed, figuring I could overriding it on the transition to Closed by changing the field state to Readonly when the reason is changed to something that is NOT Resolved (so, a WHENNOT rule), but now I have a required field that is readonly. Not helpful.

    Is this even possible?

    Angela Dugan


    Friday, March 20, 2015 9:33 PM

Answers

  • OK, I got it after seeing that other post and thinking about it some more.  I was putting the conditions on the field, and on the transition, but it needed to be on the state itself. Pretty simple solution, I think I was just over-complicating it.  Thanks again for your help!

    <State value="Closed">
      <FIELDS>
        <FIELD refname="Microsoft.VSTS.Scheduling.Effort">
          <READONLY />
        </FIELD>
        <FIELD refname="Microsoft.VSTS.Common.BusinessValue">
          <READONLY />
        </FIELD>
        <FIELD refname="FFIC.RequestLead">
          <WHENNOT field="System.Reason" value="Resolved">
            <READONLY />
          </WHENNOT>
          <WHEN field="System.Reason" value="Resolved">
            <REQUIRED />
          </WHEN>
        </FIELD>
      </FIELDS>
    </State>


    Angela Dugan

    Thursday, March 26, 2015 2:11 PM

All replies

  • Hi Angela,

    I am trying to involve someone to further look at this issue. There might be some time delay. Appreciate your patience and thanks for your understanding.

    Best regards,


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Monday, March 23, 2015 2:01 AM
    Moderator
  • Hi Angela,

    I can't find any work item type with Resolved reason, but I can find the Resolved state instead. Anyway, I will use Agile - Bug work item to give an example how to achieve your requirement. In my example below, the Request Lead field can only be editable when State = Resolved & Reason = Fixed. And for other State or Reason, the Request Lead field is disabled.

    1. Create a custom field:

      <FIELD name="Request Lead" refname="Custom.RequestLead" type="String">
            <FROZEN />
            <WHEN field="System.Reason" value="Fixed">
              <REQUIRED />
            </WHEN>
            <WHENNOT field="System.Reason" value="Fixed">
              <READONLY />
              <ALLOWEXISTINGVALUE />
            </WHENNOT>
          </FIELD>

    2. In Closed state.

     <STATE value="Closed">
              <FIELDS>
                <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
                  <READONLY />
                </FIELD>
                <FIELD refname="Custom.RequestLead">
                  <READONLY />
                </FIELD>
              </FIELDS>
            </STATE>

    3. In Active state.

     <STATE value="Active">
              <FIELDS>
                <FIELD refname="Custom.RequestLead">
                  <ALLOWEXISTINGVALUE />
                </FIELD>
              </FIELDS>
            </STATE>
    Thanks,

    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, March 24, 2015 1:47 AM
    Moderator
  • Thanks for the quick reply Vicky!

    Request is a CUSTOM work item type, so there is a "Resolved" reason because it I made that one of the options, so you're right, you won't see that in an out of the box template.  There are 5 different reason options available in my custom Request work item when moving this work item type to the closed state, Resolved being just one of the valid reasons.

    The above does not work, because it makes the reason field read-only when we move a Request to closed.  I need to be able to move this Request work item type to Closed, THEN select a reason, and then based on that reason I flip the properties of the Request Lead field. The Reason field itself should does be ReadOnly once State is changed to Closed.

    With what you have above, as soon as I flip the work item to closed the Reason field becomes Readonly and I cannot change it. If I cannot change it, then how do I ever control the state of the RequestLead Field?

    when (State = Closed) + (Reason = Resolved), Request Lead = Required

    when (State = Closed) + (<> Resolved), Request Lead = ReadOnly

    If I remove the ReadOnly attribute on Reason when state = closed, then I can change the Reason field like I need to be able to, but RequestLead remains disabled regardless of what Reason I select.  I'll keep noodling over this, let me know if you think of anything else.


    Angela Dugan

    Tuesday, March 24, 2015 5:05 PM
  • Hi Angela,

    As you defined the State & Reason in your WIT, there is a little bit confusing when I try to understand your scenairo. And the script I offered above is just based on when you edit the field on the Reason state instead of Closed state.

    So, it is better if you can share me custom WIT file, then I will check it and try editing it. You can upload it to onedrive, then post back the link.

    Thanks. 


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Thursday, March 26, 2015 8:21 AM
    Moderator
  • So compound conditionals are not supported according to this MSDN forum post that I finally found.

    https://social.msdn.microsoft.com/Forums/en-US/0bd12330-afdb-4187-a030-e3358e96be65/can-control-relationship-logic-be-coded?forum=tfspowertools


    But I'm going to spend a bit more time to see if there is a different way to accomplish it. Thanks in advance if you are able to figure this one out as well.

    Angela Dugan

    Thursday, March 26, 2015 1:51 PM
  • OK, I got it after seeing that other post and thinking about it some more.  I was putting the conditions on the field, and on the transition, but it needed to be on the state itself. Pretty simple solution, I think I was just over-complicating it.  Thanks again for your help!

    <State value="Closed">
      <FIELDS>
        <FIELD refname="Microsoft.VSTS.Scheduling.Effort">
          <READONLY />
        </FIELD>
        <FIELD refname="Microsoft.VSTS.Common.BusinessValue">
          <READONLY />
        </FIELD>
        <FIELD refname="FFIC.RequestLead">
          <WHENNOT field="System.Reason" value="Resolved">
            <READONLY />
          </WHENNOT>
          <WHEN field="System.Reason" value="Resolved">
            <REQUIRED />
          </WHEN>
        </FIELD>
      </FIELDS>
    </State>


    Angela Dugan

    Thursday, March 26, 2015 2:11 PM