Still wondering where the Action Simulator is in 2018?

It hurts to admit it, but this is just another preview and not something that is ready to be released to the general public! But don’t think that I took it easy: I spent a lot of time cleaning up and restructuring the code. I worked on new features and some fundamental issues and then I thought: Instead of going for 3.4, which is nearing its end of life, rather aim for 4.0, which will become the next LTS!

In hindsight, I am not upset with this decision, but unfortunately it added a lot more complexity to the job and that is why it is not done! This is where you could come in: I am looking for help on the frontend part. Please read on if you are interested and let me know!

If you don’t know what Action Simulator is and why is it great, consider reading the introductory post first.

But before I tell you about the improvements I did so far, I would like to thank Mihail Ohotin. Mihail jumped in to provide users with something that works in 3.2/3.4. He actually did that before, when I could not find the energy to adapt the Action Simulator for 2.4.

What has improved?

I pretty much implemented everything I announced in my previous blog post on the Action Simulator.

New features

  • The code can handle both styles of recovery notifications, recovery remote commands and acknowledgement operations
  • The code can handle user-supplied maintenance windows

UI changes

  • Now uses a 4.0-style overlay window instead of a pop-up window, which has the advantage of being able to open more than one of them without interfering
  • The action condition section is easier to read and better matches the action condition configuration design
  • The notification and the remote command section now better match their configuration counterpart
  • “Soft errors” have a yellow error icon now. Think about a user configuring not to receive SMS during the night time; That’s not quite as permanent a problem as not having defined a phone number or not having permissions for a host
“Soft errors”, fewer columns and content that more closely resembles the configuration counterpart
The new design has fewer columns than previously and better resembles the respective configuration view.

Under the hood

  • The API class no longer returns markup, which it did in some places, among many other small improvements in this area
  • Adheres to the MVC model

It’s also worth saying that messing around with other people’s code always brings up bugs and little issues. That eventually helps with the overall quality of the product. I raised 12 issues during the development and most of them are resolved by now.

What’s the problem then?

The new modal window design made it a bit difficult for me to use calendars at first, but with a little help from Zabbix frontend developers the calendars finally started working; Thank you, gregc and vjaceslavs! However, my previous work on the interface had already taught me that calendars are probably not the right approach to the kind of interface we would need here. This became even more evident for me with the 3.4 features! The calendar approach lacks clarity, flexibility and it is cluttering the interface:

Flexibility and cluttering

How many date fields can we handle? 3, 5 — even 10? Hardly!

Events can be acknowledged once, but comments can still be added several times. This is relevant to correctly process acknowledge operations. Each of them would need a date field! I also wasn’t happy with how I treated maintenance periods in the past, which was basically a choice of saying “Assume maintenance all of the time” or not. Of course, a trigger/event can potentially go through several maintenance periods, which can influence which operations are actually taking place.

Clarity

For a while I tried to generate a verbal description from the calendar data, like the one you can see in the first screenshot. This made the temporal settings a lot easier to oversee, but such a message would potentially become fairly long when considering multiple maintenance periods and acknowledgments/comments. This eventually lead me to the following design, which is unfortunately just a mock-up:

I am not much of a Javascript developer! I created this with the timeline library of visjs. It can pretty much do everything that we could ask for: Allow dragging, adding new items, showing timestamps, applying constraints and so on, as you can see on their example page. To make this more useful, the settings should be stored in the user profile. If you have some experience with Javascript development and at least a vague idea of how the Zabbix frontend works, I would greatly appreciate your help on this. Feel free to contact me via e-mail (volker27@gmx.at), IRC (volter on Freenode) or in the comments section below! Oh, and if you can figure out how to run frontend tests like those present in the Zabbix code base already, that would be another plus to make the Action Simulator more reliable.

One thought on “Still wondering where the Action Simulator is in 2018?”

Leave a Reply