-
Type:
New Feature Request
-
Resolution: Unresolved
-
Priority:
Minor
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
I believe there is a need for a user to be able to initiate an action for an active event manually from the problems applet or problems page.
There are scenarios where an event occurs and an action can not be problematically identified easily in an actions conditional arguments. As an example, I may be using a 3rd party tool to assign the problem to a user or team. The criteria needed to determine which user or team that problem (event) is to be assigned to is not available to zabbix. By allowing a user to manually initiate a pre-configured cation for that specific problem, you still provide them the ability to use the various macros
{TRIGGER.NAME},
{ITEM.LASTVALUE}, etc when running the action.
Although there are "scripts" (in the admin section), when called when left clicking on the host name next to the problem description, these scripts do not have access to the same event driven macros (listed above) when called.
In my case, I am creating support tickets in a 3rd party tool for problems identified by Zabbix. The action I already have configured for creating these tickets works as designed, however there are cases where a specific problem needs to have a ticket created even though it does not meet the "normal" criteria for that "ticket creation" action. Currently I would have to use a script from the administration section to go in and problematically search the triggers, events, alerts, and any other relevant table in the database to collect and either artificially inject a new entry in the alerts table (thus achieving roughly the same thing) or use the data to initiate a call to the ticket creation API externally. The problem with both of these issues is they are not ideal and is not reliable.
I can think of a few other cases where this might be be useful and even though about just giving the user the ability to run a script from the Administration > Scripts section. However after careful thought I realized that the user could do the same thing in an action by running a remote command. This also provides the additional benefit of ensuring the same operation and recovery steps are followed regardless of if it was manually initiated or not.
Thank you,
Carl Slaughter
Network Systems Engineer
IBM Cloud (SoftLayer)
Managed Services
Mon-Fri 9a-5p CDT