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.
- The code can handle both styles of recovery notifications, recovery remote commands and acknowledgement operations
- The code can handle user-supplied maintenance windows
- 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
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.
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: