Rules: Set field value post 4.4.4.0 thru 4.4.4.2

Forums Dynamic Forms for SharePoint Rules: Set field value post 4.4.4.0 thru 4.4.4.2

This topic contains 11 replies, has 2 voices, and was last updated by  Alexander Bautz 2 weeks, 3 days ago.

  • Author
    Posts
  • #26459

    BenR
    Participant

    Alexander,

    My configuration was 4.4.3.65 and attempted upgrade to 4.4.4.0 and 4.4.4.2. The following symptom was introduced with 4.4.4.0, and persists thru 4.4.4.2 – my current solution is roll-back to 4.4.3.65.

    Symptom: Rule includes a Set field value of a SPFieldChoice field called [Commodity Type]/CommodityType. After 4.4.4.0, the Set field value is not set, with 4.4.3.65, the field is successfully set.

    The rule definition:

    
    
    GTILOB [index: 3] (change) [09:32:00.938]
    
    Trigger: LOB
    No reversing of this rule: true
    Operator: Equals
    Target value: GTI
    Current value: GTI
    Match = TRUE
    
    Current index: 3
    TriggerMap: 1, 2, 3, 4
    
    Actions for "GTILOB [index: 3]" [09:32:00.945]
    
    Mandatory fields: 
    Optional fields: Commodity Type
    Hidden fields: Commodity Type, Non Tech Commodity Group, Non Tech Commodity
    Visible fields: Tech Commodities
    Visible headings or elements: 
    Hidden headings or elements: 
    Read only fields: 
    Editable fields: 
    Hide save item button: 
    Hide edit item button: 
    Hidden tabs: 
    Visible tabs: 
    Set field value: [{"fin":"CommodityType","val":"Tech","onlyIfEmpty":false},{"fin":"NonTechCommodityGroup","val":"- Select -","onlyIfEmpty":false},{"fin":"NonTechCommodity","val":"- Select -","onlyIfEmpty":false}]
    Display message: 
    Alert message: 
    Selected tab: 
    Run these functions: 
    Send these emails: 
    No reverse: true
    Stop and exit: false
    Jump to rule: 

    My current fix is to roll-back. As always, your support and efforts are appreciated!

    R’grds – Ben.
    Reference:
    Attempting:
    DFFS frontend: 4.4.4.2 – July 31, 2019
    DFFS frontend CSS: 4.48 / 4.48
    Autocomplete: 1.6.36 – July 31, 2019
    Cascading dropdowns: 3.7.30 – July 21, 2019
    jQuery: 1.12.4
    Lookup: 1.1.17 – July 21, 2019
    Resource management: not loaded
    SPJS-Utility: 1.336 – July 21, 2019
    vLookup: 2.2.135 – July 31, 2019

    Roll-back:
    Custom DFFS-folder: DFFS_v4.4.3.65_2019-03-31
    DFFS frontend: 4.4.3.65 – March 31, 2019
    DFFS frontend CSS: 4.46 / 4.46
    Autocomplete: 1.6.28 – January 12, 2019
    Cascading dropdowns: 3.7.26 – March 31, 2019
    jQuery: 1.12.4
    Lookup: 1.1.16 – March 05, 2019
    Resource management: not loaded
    SPJS-Utility: 1.332 – March 05, 2019
    vLookup: 2.2.129 – March 07, 2019

  • #26461

    Alexander Bautz
    Keymaster

    Hi,
    I have tested a rule which sets choice columns of all types (dropdown, radio button and multichoice) and it works as expected. Could it be one of your other rules on the same trigger (index 1, 2, or 4) that interferes?

    Alexander

  • #26467

    BenR
    Participant

    Alexander,

    Your suggestion to investigate the Trigger Map led to more information…

    What I noted: I have four Rules 1, 2, 3, & 4. Each rule triggers on Load and field change, and each rule is non-reversing.

    • Rule 1 clears the value of CommodityType
    • Rule 3 sets the value of CommodityType

    If Rule 3 is true, and the rules are fired in that order, I should find a value in CommodityType. My symptom is that Rule 3 is true, but I find no value in CommodityType.

    Setting each of the rules to debug, I load a form and set the field that makes Rule 3 true. The attached images display debug Rule trigger order.

    For 4.4.3.65, you see 8 rule triggers, 4 on load, 4 on change. Further, you see the order of 1,2,3,4 on load, and 1,2,3,4 on change.

    For 4.4.4.4, you see 3 on load, 4 on change. Note the order of 2,3,4 on load, and 2,4,3,1 on change – this places Rule 3 (set value to CommodityType) before Rule 1 (clear value from CommodityType) – which matches my symptom.

    From this, I believe the root cause is that Rule execution order in 4.4.4.4 is in error.

    R’grds – Ben.

  • #26471

    Alexander Bautz
    Keymaster

    Thanks for the explanation – can you post (or email me) a screenshot of the trigger part of each of these rules so I can recreate a test form here?

    Alexander

  • #26477

    BenR
    Participant

    Alexander,

    I hope this is the Trigger section of the four rules. If not, please advise.

    R’grds – Ben.

    • #26483

      Alexander Bautz
      Keymaster

      Yes, this is the correct screenshot, but I forgot that you mentioned that one of the rules clears the same field it triggers on – can I ask you to send screenshot of the entire rule config – including the set field value part of these four rules?

      Alexander

  • #26480

    BenR
    Participant

    Alexander,

    Could the fact that the trigger field is the first-tier of a two-tier cascading dropdown contribute to this issue?

    R’grds – Ben.

    • This reply was modified 3 weeks, 1 day ago by  BenR.
    • #26485

      Alexander Bautz
      Keymaster

      Not sure if that makes any difference.

      Alexander

  • #26489

    BenR
    Participant

    Alexander,

    The field that displays the symptom is [Commodity Type]. This field is cleared in Rule-1, and set in Rule-3. However, Rules-1,-2,-3,and -4 are triggered on a different field called [LOB].

    Full Rules screen captures follow.

    R’grds – Ben.

  • #26497

    Alexander Bautz
    Keymaster

    Thank you for the detailed explanation. I have recreated these rules in a test list and think I have sorted this out – it was a problem with the execution order of the matched rules.

    I’m still investigating another (unrelated) small issue, but hopefully I’ll be able to publish a new version this weekend or early next week.

    Best regards,
    Alexander

  • #26526

    BenR
    Participant

    Alexander,

    I’ve tested with DFFS_v4.4.4.4_2019-07-08 released today…

    My symptom was caused by Rule execution order, and v4.4.4.4 does remove the symptom.

    The Rule execution order does not match v4.4.3.65, where it appeared that rule order simply followed index number 1,2,3,4. It appears that in v4.4.4.n, rule order seems to be FALSE ascending then TRUE ascending – but this is my unfounded guess. (Screen shots follow comparing two versions…)

    At the end of the day, this symptom is resolved! As always, thank you for your support and efforts!

    R’grds – Ben.

  • #26537

    Alexander Bautz
    Keymaster

    I’m happy to hear the issue is fixed. The reason for the strange order of execution when you have multiple rules on the same trigger is that the rules evaluating to false will be executed first to ensure the ones that are evaluated to true overrides any actions in the false rules.

    For example if a rule with index 5 is false, and hides a field while a rule with index 4 is true and shows the same field.

    If the rules should be executed in order from 0 and up this would happen:
    Because of the default reversing of the unmatched rules (you can turn this off though) the rule with index 5 would set the field as hidden while the expected behavior (in my opinion at least) is that the true rule should be the one winning the battle of the field visibility.

    Alexander

You must be logged in to reply to this topic.