Allow multiple values for tags

[nilmerg]

Host and service group tags are currently structured as follows:

• hostgroup/<name>
• servicegroup/<name>

This has been designed to circumvent the need for multiple values for the same tag name.

The side effect that filters need to handle such as columns, has been accepted as limitation. (hostgroup/linux&hostgroup/windows)

Though, for several reasons, including results from user testing and general feedback, this needs to change and we need to streamline tag structure somewhat.

The current structure of Icinga 2's tags are not intuitive to users and would require that Notifications Web to use a different implementation to handle Icinga 2 tags and all others. Additionally, by using prefixes ourselves, we introduce a precedent which I'd not want to support in the future. (in Web)

This means that tag names must not contain any values. Hence why e.g. hostgroup/linux must be hostgroup=linux.

Regarding filter semantics, this means the following:

hostgroup=linux|hostgroup=windows (The object must match at least one of the expressions)
hostgroup=linux&hostgroup=windows (The object must match both expressions)

The unequal != operator must be considered the inverse of equal =. If hostgroup=linux would match, hostgroup!=linux cannot.

Negation (!(...)) doesn't need to be supported right now.

[julianbrost]

Negation (!(...)) doesn't need to be supported right now.

Implementing this in the intuitive way, i.e. just inverting the boolean value of ... would be trivial in our code.

What about !=? Would hostgroup!=prod mean "is not in prod" (all values of hostgroup are not prod) or "is in a hostgroup that's not prod" (one value of hostgroup is not prod, i.e. a host with tags hostgroup=prod and hostgroup=cloud would match that filter).

[nilmerg]

Negation (!(...)) doesn't need to be supported right now.
Implementing this in the intuitive way, i.e. just inverting the boolean value of ... would be trivial in our code.

Didn't we discuss this? Web can't handle this right now.

What about !=?

Added.

Would hostgroup!=prod mean "is not in prod" (all values of hostgroup are not prod) ?

This.

[julianbrost]

Negation (!(...)) doesn't need to be supported right now.

Implementing this in the intuitive way, i.e. just inverting the boolean value of ... would be trivial in our code.

Didn't we discuss this? Web can't handle this right now.

Yes, but "doesn't need to be supported right now" isn't very helpful for implementing this. I doubt there would be a reasonable definition for unary negation besides that one, so we could say that this is the desired behavior that's so far only implemented by the daemon but not yet by web. Alternatively, we have to replace our current implementation with an "sorry, not supported" error.

[nilmerg]

I doubt there would be a reasonable definition for unary negation besides that one

I do. At least, as long Icinga DB Web's implementation is broken (and never worked), I prefer not supporting this and see if users miss it at all.