- if detected, they will be replaced with their real name on the command
line (instead of $ARGn$)
- if macro is resolvable, its value will be added to the macro
dictionary
- if macro is not resolvable, it will be skipped and left for the core
to resolve the macro on runtime.
caveat: getting host/service attributes requires lookups from the object
into the template tree, as well as host macros on services a search on
the host object itsself.
note: macro resolver is rudimentary implemented. there's space for more
detailed if-macro-name-is-then-return-attribute-abc. main problem are
the missing underscores in macro names, but not in attributes (what the
...?).
fixes#4700
collect attributes
* notes
* icon_image
* icon_image_alt
* action_url
* notes_url
* statusmap_image
* 2d_coords
* _CVs
* !__I2CONVERT
and stash it onto the custom dictionary.
note: attribute names starting with a number need to be quoted.
fixes#3096
parsing the existing comma separated list and using some perl hash magic
to convert it to the new notification_type_filter and
notification_state_filter logic.
fixed missing file permission check on writing config files too.
fixes#4060
requires a new functionality to grab all service names by a given
servicegroup name. this only works after reprocessing all services with
their updated "servicegroups" attribute as array in the 2.x objects
hive.
after fetching the service names and their logical objects, it's quite
the same procedure as for the hostgroups and single
host_names/service_descriptions - for better reading, code remains
duplicated for now.
furthermore, escalation notification template objects are only added
based on the old contact->notification_command, and only a reference
template added when using within the service linking.
refs #4009
- fixed bug with contactgroups in plain notifications
- fix bug with duplicated notifications (duplicate detection logic based
on names, not template names)
- contacts may use templates too, and hide required values there
(commands)
- added attribute getters which take templates into account (required
for service -> notification_interval multiplied with service escalation
first|last_notification too)
- apply the service escalation -> users -> commands as well as linking
new notification with users, and services, defined either with
* host_name/service_description
* hostgroup_name/service_description
* servicegroup_name (TODO)
- code duplication due to many nested loops with group wildcards
in short - we know why icinga 1.x takes ages to apply escalation.
because they look like added under pressure, and make no logical sense
compared to the rest. in short - they suck.
refs #4009
Gunnar Beutner
Michael Friedrich