FR: Nested Conditions in Rules & Processes

[johntalbott]

Currently the IF conditions in Rules & Processes require a lot of condition duplication in order to evaluate every combination of conditions independently. It's inefficient from a config standpoint. But more importantly, it wastes a lot of server resources in the way of processing cycles, memory, etc.

Nested If conditions would increase configuration efficiency and also run much more efficiently meaning faster response times and support for more concurrent users.

Example:

Without Nested If's, every combination of conditions has to be checked independently.

IF Account.Active = True AND Account.Balance = 0 THEN
Do Action1
ELSE IF Account.Active = True AND Account.Balance > 0 THEN
Do Action2
ELSE IF Account.Active = True AND Account.Balance < 0 THEN
Do Action3

With Nest If's, if an Account is Active, the evaluation of the nested conditions continues. If an Account is not Active, the rule evaluation process stops after the first IF.

IF Account.Active = True THEN
IF Account.Balance = 0 THEN
Do Action1
ELSE IF Account.Balance > 0 THEN
Do Action2
ELSE IF Account.Balance < 0 THEN
Do Action3

[RocketRod]

+1 Would love this.

Cheers Rod

[pureist]

great idea.
particularly useful when a rule is being evaluated constantly.
Support: if for some reason you didn't want to just permanently change the implementation of IF.. ELSEIF to be nested, you could perhaps differentiate between the existing implementation and the new nested implementation by way of introducing/using CASE.

[BLOMASKY]

IF Account.Active = True THEN
IF Account.Balance = 0 THEN
Do Action1
ELSE IF Account.Balance > 0 THEN
Do Action2
ELSE IF Account.Balance < 0 THEN
Do Action3

2 things...


1). It would have to have an "ENDIF" since, you would never know when the inner IF finished. (i.e. in your example, the last ELSE, might be part of the 1st IF or the 2nd IF.

But, am just nitpicking, since I am sure our favorite developer, if implementing this, will come up with the appropriate syntax.

2). you can do this now with 2 processes... 1st one just has: IF Account.active then PROCESS2
and Process2 would have the rest of the logic. but of course, that would not help much in a rule.

bruce

[johntalbott]

It's true there would need to be a way to indicate the end of an outer condition. I thought that went without saying.

One might be able to get close to simulating this with a rule that calls different processes based on a single condition, but what if you need to go another level or two deep?

Imagine having a rule that based on a single condition calls a process that based on another single (child) condition calls a process that based on another single (grandchild) condition call's a process, etc. That would become a massive mess in a hurry.

[hpl123]

1+