bug? Intelligent (Progressive) Capture Branch - 'is in' condition appears to be always true even though condition is not met

[Martyn Houghton]

When using the 'is in' condition on a conditional branch in Intelligent (Progressive) Capture, the condition appears to always appears to evaluate as true even though the condition is not met.

Example

Condition used to branch to form with custom Priorities 1 to 5 on. Added Organisation Id is set, in case it was evaluation of nulls, but issue persists.

Example using internal contact, so organisation id not set.

 

Example using external contact in organisation id is not 772 or 245.

Cheers

Martyn

 

 

[NeilWJ]

Hi @Martyn Houghton,

The problem is that that the serviceid and orgid are returned as string types from the SM even though the real data type is a numeric. So the test is failing i.e. say you are checking for is in 123,456

The flowcode var returned is "123" meaning the test equates to:-

[123,456].indexOf("123")

This fails because "123" is not the same as 123

I will have a look at putting in some logic to check the "testing values" and the "variable" value...so if the test values are all numeric i.e. 123,456 and the variable value is "123" which can be cast to a number 123 

Will let you know how get on.

Cheers

[Martyn Houghton]

@NeilWJ

Thanks for the detailed response. Having the ability to use 'is-in' saves a lot of different branches and allows us in essence us a more complex logic grouping lots of OR's.

Cheers

Martyn

[NeilWJ]

Hi Martyn,

So this should be fixed in new admin ui and is out live.

You will need to redo the condition as it is generated at design time. I have modified condition builder so all values in an [is in] or [not in] are treated as the same type. So regardless if data is "1" or 1 the test will do is "1" in/not in ["1","2","3"]. Can you let me know if that works for you.

Thanks,

[Martyn Houghton]

@NeilWJ

Thanks, I will arrange to give it a test.

Cheers

Martyn

[Martyn Houghton]

@NeilWJ

Still seem to be having some issues. Below is still resulting in true all the time.

Can I just check when entering values do I need to enclosed them in quotes, i.e. "1","2","3"?

Cheers

Martyn

[NeilWJ]

Hi Martyn, 

I totally forgot about fields. I only applied fix to flow conditions. Your original post was about pcf flow conditions?  It will be same issue, so will apply fix there too.

You do not need to enclose your test values with quotes.

Cheers

[Martyn Houghton]

@NeilWJ

Thanks for confirming the syntax. Indeed, using the same 'is in' in both flow and conditional field criteria.

Can you let me know when the fix has been rolled out?

Cheers

Martyn

[NeilWJ]

@Martyn Houghton,

Should be live now, since Thursday, in both areas.

Cheers

[Martyn Houghton]

@NeilWJ

I have rebuilt the criteria on the field condition and republished the Intelligent Capture, but still have issues with the logic always returning true.

Cheers

Martyn

 

 

[NeilWJ]

@Martyn Houghton,

Can I get you to raise a support request as will need access to your instance to run the capture and debug it to see what the data and the expression is doing. 

When logging request can you provide the captured/name and how you are running it (from a Catalog service or straight from service desk table view etc)

Cheers

[Martyn Houghton]

@NeilWJ

I just narrowed the issue down to it being the textual field 'is in' condition. The numerical one is working as expected now, but the textual one seems to be tripping it up.

I will raise a support request.

Cheers

Martyn

[NeilWJ]

It could be that for some reason the variable ref Service details->CatalogName is not actually set so test just fails. We will def need to access to instance to see what data is being used.

[Martyn Houghton]

@NeilWJ

Logged as IN00172061.

I also tested it with the additional condition to check the catalogName was being passed and the field still appeared.

Cheers

Martyn

[NeilWJ]

Hi @Martyn Houghton,

I have found issue. To demonstrate:-

1. if you open the condition form with your browsers dev console open (F12)
2. Then change the "is in" from [Question,Incident] to [Question,Incident,testerror]

You will see the raw generated condition displayed in the browsers dev console. You should see that it only generate the "is in" part of the condition and does not do the "!=" or the "is set".  This is because of a bug in constructing [is in] loop breaking out of the whole condition construction loop.

If you can confirm that is what you see happening. 

So this is why condition always passes (or fails) because it is only testing the first bit when [is in /is not in] is the first test in the condition. If you put the [is in/is not in] as the last test in the condition it would construct the full condition properly (assuming there is only 1 is in/is not in text in the condition).

Will let you know when fix is published - should be this week.

Cheers
 

[NeilWJ]

and to show the difference with fix applied, a condition fully generated...

[Martyn Houghton]

@NeilWJ

I can confirm we are seeing the same in the console where only the condition is only generated up to the is-in one.

Thanks for the detailed reply.

Cheers

Martyn