Announcement

Collapse
No announcement yet.

BPM Change of behaviour

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • MatLudlam
    replied
    Thanks for the help.

    Leave a comment:


  • yuri
    replied
    Checks whether a field is set with a value.

    Code:
    yourField != null

    Checks whether a field is set with 0.

    Code:
    yourField == 0

    Checks whether a field is set and not 0

    Code:
    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.
    Last edited by yuri; 04-01-2021, 04:38 PM.

    Leave a comment:


  • MatLudlam
    replied
    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.

    Leave a comment:


  • yuri
    replied
    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.

    Leave a comment:


  • yuri
    replied
    By using formula.

    Code:
    yourField != null
    Code:
    yourField != 0

    Leave a comment:


  • MatLudlam
    replied
    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.

    Leave a comment:


  • yuri
    replied
    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.

    Leave a comment:


  • MatLudlam
    replied
    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:

    PHP Code:
    $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.

    Leave a comment:


  • yuri
    replied
    0 has been considered empty in PHP world.

    You can utilize formula condition:

    Code:
    yourField != null

    Leave a comment:


  • MatLudlam
    replied
    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

    Leave a comment:


  • yuri
    replied
    Hi Mat,

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

    Leave a comment:


  • MatLudlam
    started a topic BPM Change of behaviour

    BPM Change of behaviour

    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:
    Click image for larger version

Name:	Stage.png
Views:	275
Size:	17.4 KB
ID:	69269

    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
Working...
X