Enrich custom variable lists in monitoring and icingadb details

[nilmerg]

resolves #2239

requires Icinga/icingaweb2#4614 or Icinga/icingadb-web#467

[Thomas-Gelf]

I really like the motivation behind this feature request and the possibilities this hook provides.

Problems spotted in this pull request: field resolution cannot be solved by joining field names with variable names. It's perfectly legal to configure the very same field multiple times, with different labels, different settings/rules and in different categories. Fields might also be provided via Hook.

This means that walking the template tree in the right order, dealing with fields with filters and fields overriding fields at template level are part of this task.

To avoid duplicate logic, you could leverage IcingaObjectFieldLoader, as it is doing exactly this. I'd suggest to run & populate it, then get the form elements and pick their labels and values. If you need to restructure that class please let me know, I'm sure I can help you saving some time with that task.

[nilmerg]

I've made use of IcingaObjectFieldLoader now, thanks for this hint. Though, IcingaObjectFieldLoader::getFields() already seems to work fine with the template tree and hooks, no need to access any form elements. 🤔

[nilmerg]

Please don't merge yet, or give me a hint when you plan to do so. I'm currently playing with an idea to extend this to data exports. (So that your hidden option for strings also works in json and csv exports)

[nilmerg]

Please don't merge yet, or give me a hint when you plan to do so. I'm currently playing with an idea to extend this to data exports. (So that your hidden option for strings also works in json and csv exports)

Nope. Changed my mind. Nothing to do here. You can merge, if you are fine with the changes.

[Thomas-Gelf]

Hi @nilmerg,

I discussed this thoroughly with @lippserd, there are some problems with this Hook. The variable rendering part is fine, the way variables are iterated is the problem. We already agreed on a slightly different implementation, with only some smaller details left for clarification. We also had a customer interested in pushing the finalization of this, it was part of a deal with a vSphereDB-related feature.

Unfortunately, this hasn't been accepted from our side for unknown reasons, so I have to skip this right now. We'll find a solution, don't worry - but not today.

In the meantime, thank you for your effort!

Cheers,
Thomas