Data Field type not handled correctly in Notification Apply Rules

[ix-dev]

Expected Behavior

We noticed some strange behavior when we define custom Data Fields and try to match them in a Notification Apply Rule.

We tried to define a Data Field of type "Number" and configure this Data Field as Custom Variable of a Service Object. We also configured a Notification Apply Rule (applied to Services) that used an equality check to test for a specific value of this variable.

We expect that we can use numeric test conditions (equality in the original case) in the "assign where" clause.

Current Behavior

The Notification Apply Rule does not apply, because the "assign where" condition tests for string-equality, the generated condition is

service.vars.test_number == "1"

although test_number is defined as "Number".

There seem to be a lot of corner cases that I will try to summarize below.

Possible Solution

Steps to Reproduce (for bugs)

Please see the screenshot on the configuration of the Data Fields and the Notification Apply Rule.

Then we add the Data Fields to a Service Template and have a service object that imports the template.

Now there are several problems when you configure the custom variables on the service:

1. If you set test_number to 2, then the rule applies as expected
2. If you set test_number to 1, then the rule does not apply, i.e., integer 1 != string "1"
3. If you set test_number to "1", then it complains: '"1"' does not appear to be an integer
4. If you set test_string to 2, then it seems to work (probably 2 is implicitly cast to string "2", not sure if this is intended)
5. If you set test_string to "2" or ..
6. If you set test_string to 3, then the config deployment fails with:

[2019-07-03 11:47:03 +0200] critical/config: Error: Error while evaluating expression: Operator > cannot be applied to values of type 'String' and 'Number'
Location: in [stage]/zones.d/master/notification_apply.conf: 188:123-188:150
[stage]/zones.d/master/notification_apply.conf(186):     import "Generic Alarm By Email"
[stage]/zones.d/master/notification_apply.conf(187): 
[stage]/zones.d/master/notification_apply.conf(188):     assign where (service.vars.test_number == "1" || service.vars.test_number > 1) || (service.vars.test_string == "2" || service.vars.test_string > 2)
                                                                                                                                                                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[stage]/zones.d/master/notification_apply.conf(189):     users = [ "test-user" ]
[stage]/zones.d/master/notification_apply.conf(190): }

    (0) Evaluating 'apply' rule 
  (in [stage]/zones.d/master/notification_apply.conf: 185:1-185:49)
    (1) Evaluating 'apply' rules for service '18298!service_2'

Your Environment

• Director version (System - About): v1.6.2
• Icinga Web 2 version and modules (System - About): 2.6.2
• Icinga 2 version (icinga2 --version): v2.10.3-294-g36fe6be
• Operating System and version: Debian GNU/Linux 9
• Webserver, PHP versions: Apache/2.4.25, PHP 5.6.40-0+deb8u2

[wp-perc]

+1. This happens for every Apply Rule (just found out using Apply Rules for HostGroups).

I am traying to implement something like: "Any IP in Subnet 10.171.252.0/24 where the fourth IP is higher than 127". The most flexible way is to convert host.address into an array of numbers and work with the required octects.

As you can see, Director renders the first 3 numbers as String, where the fourth is rendered as a Number. Because of this, this filter simply does not match.

object HostGroup "test2" {
    display_name = "Collection x notifiche Data Center"
    assign where host.vars.address_octects[0] == "10" && host.vars.address_octects[1] == "171" && host.vars.address_octects[2] == "252" && host.vars.address_octects[3] > 127
}

I believe is related to the operator, because if I change the operator from = to > or < Rendering works fine. Please fix it, because it is very annoying.

Director version: 1.8.1

[cmaile]

Bug still present in the current version v1.10.2.