BPM Change of behaviour

[MatLudlam]

Thanks for the help.

[yuri]

Checks whether a field is set with a value.

yourField != null

Checks whether a field is set with 0.

yourField == 0

Checks whether a field is set and not 0

yourField != null && yourField != 0

You can combine regular conditions (built with UI) and formula conditions. E.g. your first 2 date fields are in regular All condition group. Your int (or float/currency) is in formula.

Note if your field is float (or currency) you need to use 0.0 instead of 0 in formula.

[MatLudlam]

Ok, thanks.

Can you let me have 2 lines of formula then? One that allows me to check if something has been assigned or not i.e. "Empty", and another that lets me check if 0 or not.

Thanks in advance.

[yuri]

I see that we use non strict comparison for equals and not-equals. I think it's reasonable to make it strict in the future so that types are taken into account, null and 0 would be considered as non-equal.

Before this I recommend utilizing condition written in formula.

[yuri]

By using formula.

yourField != null

yourField != 0

[MatLudlam]

Hi yuri, from what I can see ESPO knows the difference between 0 and "Empty", because when it displays the value, it is either 0 or "None".

How do I test for an assigned value of 0? I want different behaviour depending if the value is unassigned or 0.

Thanks.

[yuri]

I don't understand the question.

1. Workflow 'not empty' resolves 0, '', null, false values to false.
2. Workflow 'empty' resolves 0, '', null, false values to true.

These are things that CAN NOT BE changed at this moment and I consider them as OK.

If you utilize formula from my example, it will check whether value is not set.

PHP has === operator that takes into account types when comparing values.

[MatLudlam]

Is taht really going to work? My field is an integer, into which I am storing 0.

In a simple PHP test, both numeric zero and null are considered the same:

$myVar =null;
if ($myVar == null ) {
echo "was null";
} else {
echo "was not null";
}
echo "<br/>";

$myVar = 0;
if ($myVar == null ) {
echo "was null";
} else {
echo "was not null";
} 

This code takes the "was null" route in both cases. I know you said use "!=", which I did and got the same behaviour.

Are you saying that ESPO has special rules to deal with "!="?

Somewhere, behind the scenes ESPO knows the difference between a numeric field assigned the value 0 and un-assigned; I just don't know how to test for it.

Thanks for the help.

[yuri]

0 has been considered empty in PHP world.

You can utilize formula condition:

yourField != null

[MatLudlam]

Hmmm, well I suppose I may not have had items of 0 value go through, I will check and get back to you.

Separately, is "0" considered as "Empty" elsewhere in the system? The "Empty" status seems to relate to the SQL Null handling, and that differentiates; null and 0 are different.

My feeling (although I cannot remember explicitly testing it) is that 0 and Empty are different elsewere.

Thanks

[yuri]

Hi Mat,

I compared the code with older versions. There was no any change. Integer 0 seems always has been treated as empty.

[MatLudlam]

Hi I have a BPM that I have been using for some time (say 4 months) without fault. It has recently started to get "stuck" at the following stage:


The first two elements of this work fine, it is that "Actual Margin" being "not empty" that has started to play up. Historically the value of 0 didn't count as empty so would pass straight through this stage. Now, if the value is 0, it waits. When I set the value to 1 it then moved on, and I have to put the value back to 0 after.

My current version is 6.1.4 on the SaaS platform.

Thanks