Inconsistency in object filtering

[peteeckel]

Summary

The behaviour of object filters for roles is inconsistent within the GUI and with object filters in the roles configuration, and it is lacking some essential functionality.

Steps to Reproduce

Create the following Icinga 2 configuration:

object HostGroup "test-hosts" {
    display_name = "Test Hosts"
}

object HostGroup "prod-hosts" {
    display_name = "Production Hosts"
}

object ServiceGroup "test-services" {
    display_name = "Test Services"
}

object ServiceGroup "prod-services" {
    display_name = "Production Services"
}

object Host "test-host1" {
    check_command = "dummy"

    groups = [ "test-hosts" ]
}

object Host "prod-host1" {
    check_command = "dummy"

    groups = [ "prod-hosts" ]
}

object Service "test-service1" {
    check_command = "dummy"

    host_name = "test-host1"

    groups = [ "test-services" ]
}

object Service "test-service2" {
    check_command = "dummy"

    host_name = "prod-host1"

    groups = [ "test-services" ]
}

object Service "prod-service1" {
    check_command = "dummy"

    host_name = "prod-host1"

    groups = [ "prod-services" ]
}

This creates a minimal test setup to reproduce the bug. Two hosts, one in each of the groups test-hosts and prod-hosts, one service in group test-services on test-host1, one service in group test-services and one in group prod-services on prod-host1. Representation in the service grid:

A typical filter for this setup would be one that shows only production hosts and services and neither test hosts or test services on production hosts.

Set up that filter in the Icinga Web 2 filter editor:

Works exactly as expected: Only service prod-service1 on host prod-host1 is displayed.

Applying the same filter to e.g. the Event Overview, however, filters prod-host1 as well, although there are events for prod-host1 they are not displayed:

Removing the service group filter reveals the events for host prod-host1:

The culprit here seems to be that the servicegroup_name!=test-services term evaluates to false when there is no servicegroup_name attribute for an object, e.g. a host. That way, the compound term hostgroup_name!=test-hosts&servicegroup_name!=test-services always evaluates to false for hosts.

This is a) inconsistent with the behaviour in the service grid (where the above term does what you would expect and exposes both the host and the service) and b) creating a major problem: There is no way to set up a filter that does the job of limiting access/visibility to production hosts and services only, which is a fairly common task. There is obviously a whole bunch of other cases where this limitation applies.

Possible solution

IMHO there is a fairly simple solution to this dilemma: Have the not-equal operator != default to true instead of false when one of its operands is undefined.

[nilmerg]

Hey, sorry for answering this so late.

The culprit here seems to be that the servicegroup_name!=test-services term evaluates to false when there is no servicegroup_name attribute for an object, e.g. a host. That way, the compound term hostgroup_name!=test-hosts&servicegroup_name!=test-services always evaluates to false for hosts.

That's not the case. We do exactly what you suggest below.

The problem you have with this filter being applied to the event overview is exactly what #3550 is about. This is not a bug and the way around the limitation are custom variables which do not show the same behavior.

You're right with the inconsistency in the servicegrid. Though, it's not a bug but due to the nature of this view it's showing the expected result. The grid view issues two queries, one for each axis. The filter then is only applied to either only hosts or services. Which is what the operator we'd intend to implement for #3550 and #3349 also does.

So, the inconsistency is the thing that's left. Honestly, I don't care much about this. It's neither wrong nor bad. To solve this, we'd need to make it to also show the same behavior as the remaining views. (Not showing prod-host-1, as in your example) Which is in all honesty, not worth the time.

As I said previously, the solution is to use custom variables for such cases. The queries also run much faster with filters like these. Filtering on host- or service-groups is really the least effective thing here.