man Zabbix::API::Trigger (3): Zabbix trigger objects

SYNOPSIS

use Zabbix::API::Trigger;
# TODO write the rest

DESCRIPTION

Handles CRUD for Zabbix trigger objects.

This is a subclass of "Zabbix::API::CRUDE"; see there for inherited methods.

METHODS

collides(): Returns true if the trigger exists with this description, false otherwise.
hosts(): Accessor for a local "hosts" attribute, which it also sets from the server data when necessary (when it is not yet set, which happens when the trigger has just been fetched or immediately after a pull or push --- this is because a trigger's notion of its host(s) is ``whatever is referred to in the trigger expression''). The value returned is an arrayref of "Zabbix::API::Host" instances.
items(): Same as "hosts()", for items.
dependencies(): Same as "hosts()", for dependencies (which are "Trigger" instances).
add_dependency(DEPENDENCY): Add a dependency to this trigger. The dependency can be a trigger ID (an integer), or a "Zabbix::API::Trigger" instance.
remove_dependency(DEPENDENCY): Remove a dependency from this trigger. The dependency can be a trigger ID (an integer), or a "Zabbix::API::Trigger" instance. Unlike the web API method, this method removes a single dependency.

BUGS AND LIMITATIONS

The "expression" data attribute stored in "Zabbix::API::Trigger" instances is actually an expression ID. This is what the web API returns. Expressions are also not mapped by the web API, so this is all you get (well, you can get the list of hosts and items mentioned in the expression). If you plan on using this distribution to manipulate trigger expressions, a workaround is to have the trigger just use a calculated item in a very simple expression, since items work as expected.

Since the web API does not expose a method through which dependencies can be removed individually, the "remove_dependency" method works around this by deleting all dependencies then adding back the rest.

AUTHOR

Fabrice Gabolde <[email protected]>

COPYRIGHT AND LICENSE