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

Viewing 9 reply threads
  • 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 months, 2 weeks 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

Viewing 9 reply threads
  • You must be logged in to reply to this topic.