- This topic has 11 replies, 2 voices, and was last updated 5 years, 3 months ago by
.
-
Posts
-
-
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, 2019Roll-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 -
-
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.
-
-
Alexander,
I hope this is the Trigger section of the four rules. If not, please advise.
R’grds – Ben.
Attachments:
-
-
-
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.
-
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 -
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.
-
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.