schema: Require & use citext extension

[yhabteab]

To allow case-insensitive matches when filtering by these columns.

cc @nilmerg

[julianbrost]

I think most changes should be fine, but others probably need individual/more careful consideration (see individual comments).

In general:

• The changes that don't have individual comments should be fine for doing them immediately.
• All the others should probably be discussed first, so please don't treat the comments as change requests for now.

If the changes without individual comments are useful enough on it's own, I'd do them first and postpone the rest to a later point. /cc @nilmerg

[nilmerg]

Display names should be case-insensitive, as they're used as quick search columns in their respective view. This affects sources, schedules, rules, channels, contacts and contactgroups.

Id tags, or tags in general, should be case-sensitive on the other hand. They resemble e.g. icinga object names, and these are also case-sensitive. This also applies to extra tags. In Icinga DB, custom variable names are case-insensitive as this was the case in the IDO as well. Here we have no such predecessor with which we should be compatible. So being case-sensitive should be our way to go here.

The username (referencing the name of a contact in the interface) should be case-insensitive, as that's what it is in Web anyway.

[julianbrost]

Change itself looks fine for me now, if @nilmerg gives an ok as well, we can pick the correct sequence number for the upgrade file and merge it.

[yhabteab]

Change itself looks fine for me now, if @nilmerg gives an ok as well, we can pick the correct sequence number for the upgrade file and merge it.

Ping @nilmerg

[nilmerg]

Extra tag values should be case-insensitive.

[julianbrost]

Extra tag values should be case-insensitive.

Why? That would mean that the object_id_tag and object_extra_tag tables would become inconsistent. Is that really intended?

[nilmerg]

Because that's what users expect. Another reason, by the way, why we shouldn't hide values in names. Inconsistent? Of course they are. They have different names after all... (I don't see any reason why any inconsistency should be of interest here)

[julianbrost]

Because that's what users expect. Another reason, by the way, why we shouldn't hide values in names.

That would result in searching by host name being case-sensitive but searching by host group name being case-insensitive. To me, that doesn't sound like something anyone would expect.

[nilmerg]

Fair enough. But then I'd propose a second column for each with a _ci suffix. Would you like that?

No, seriously. Web differentiates between id and extra tag, so a user should not be surprised that they are handled differently.

[julianbrost]

No, seriously. Web differentiates between id and extra tag, so a user should not be surprised that they are handled differently.

On the other hand, for rule.object_filter, neither the filter syntax nor the daemon differentiates between ID and extra tags. Changing this would mean that filtering for a key there would be case-sensitive or case-insensitive on a per-object basis, depending on whether this object gave the key as ID or extra tag.

Fair enough. But then I'd propose a second column for each with a _ci suffix. Would you like that?

First of all, I'd like to know the reason for the change and not just some vague claim that users expect it. I mean for most of the columns changed in this PR, I don't care too much as the most the daemon has to do with them is to just copy it's value somewhere (to a log message, or a notification message maybe). But for tags, this is different, as they have to be compared by the daemon as well.

[nilmerg]

It's not just a vague claim. During the user testing at OSMC last year, we noticed that user's don't make much of a difference how a lookup for a value (in the searchbar) and how a filter for one works.

Take this example:

It doesn't make a difference which suggestion you choose or whether one at all. You'll find hosts with a custom variable called department set to backend.

Or phrased differently: You'll see the value backend and you'll find hosts that use this value. It doesn't matter whether you look for this value in the searchbar or whether you search for it as part of a filter.

Now, what this means for case-sensitivity is this: If the lookup in the searchbar is case-insensitive, the filter must as well.

And this is what the user testing also showed: Users expected the lookup in the searchbar to be case insensitive.

So if I look for baCK, I'll get backend as suggestion and with department=baCK I should find objects matching department=backend.

[julianbrost]

Doesn't that argument boil down to "if it appears in a search bar, it should be handled case-insensitively everywhere"?

Otherwise, how would you explain that host~*.prod.example.com does not match SOMETHING.PROD.EXAMPLE.COM (because well, that happened because Windows happens to love upper-case host names).

Case-handling is messy already within Icinga:

• Icinga 2 treats everything as case-sensitive: vars.x and vars.X refers to different variables, the == operator in API/apply rule filters compares case-sensitively (you can manually use .lower()).
• In Icinga DB, custom variable names are case-insensitive, custom variable values on the other hand are case-sensitive (https://github.com/Icinga/icingadb/blob/v1.2.0/schema/mysql/schema.sql#L989-L990, if you read the corresponding PR history back then, I think you can tell that I wasn't convinced back then either: Schema: Make custom variable names case insensitive icingadb#456).

The change you're asking for is inconsistent with both (I don't know if there's something else it's consistent with) and would even introduce inconsistencies within this project. I'm sorry, but I fail to see how this is an improvement.