Read Only User - Permission to Pause Alerts

For each user account you can set "Allow Acknowledge Alarms" to "Allow" or "Deny" (in PRTG 12).

This way the read-only users can acknowledge alarms (but they can not pause a sensor, this requires "write" rights.

The issue with this for our scenario is that, in the event that a site or a device is flapping or intermittently down/up for some reason only those with write access can pause a device or sensor to prevent constant re-alarming.

In our environment it would be ideal if we could be even more granular than PRTG currently is regarding permissions. For instance, one additional level would allow quite a bit of additional flexibility in my opinion:

None: The object will not be displayed to the users of the group; no logs, no tickets, no alarms regarding this object will appear. Read : Only monitoring results can be seen. Add Write : Reviewing monitoring results and editing settings is allowed. In addition, objects can be added to the device tree and paused for a certain timeframe but not deleted or paused indefinitely. Modify Write/Delete : Reviewing monitoring results and editing settings is allowed. In addition, objects can be added to and deleted from the device tree as well as paused indefinitely. Full : Reviewing monitoring results, editing settings, and editing access rights is allowed. In addition, objects can be added to and deleted from the device tree. Admin rights : If a user group has administrator rights, all options are available, including creating users, creating user groups, and deleting objects from the device tree. Access restrictions to objects cannot be set for this type of user group.

This allows a new user class that has permissions to add and pause for a specific timeframe but not pause indefinitely as that has been a huge source of problems for our service desk personnel. Alternately, even a Read account that can also pause for a specific timeframe would be extremely helpful but our organization and others running PRTG that I have discussed with have expressed the desire to allow some class of user that can add resources and pause them but not delete them or pause them indefinitely.

If this new rights class were added and another option was added to read only users that allows them to not only acknowledge but pause sensors (but again not indefinitely), I don't see that any further rights enhancements would be necessary as we would then have the granularity to establish whatever type of rights were required for our different tiers of service and engineering personnel.

Hi Blake,

thanks for your suggestion. But I am afraid I have to tell you, that we will not implement something in that direction anytime soon.

It is the classical product manager dilemma: A customer suggests a nice feature which makes sense to him and x% of the users. But although I understand your need I have to decide not to implement this into our product because of added complexity - internally in the code and externally in the UI. The hardest job for the product manager is to say "no" so many times in order to keep the software easy to use and quick to understand. In just one week I have to decide like this more often than I have fingers on my hands. But for our customers as a whole this is the right thing to do. Otherwise we would already have a bloated, unusable software. PRTG is as it is today because we have learnt to say "no" often.

I am not saying that your suggestion is not good. I do like it. But immediately I can remember at least 5 other customers just from the last 6 months that have requested similar changes to PRTG - similar but still different. There is no way we can follow all these requests as long as there is no common ground that covers almost everybody. From a bird's eye view too many new and far reaching features clutter the software and render it less usefull than it can be.

And, finally, it does not go into the strategic direction that we want to go with our product. We have a clear vision on what we want PRTG to be and we are working hard to combine that with as many customer requests as we can.

So, what can you do: Please consider creating the required functionality using our API. This may require some code development on your side. It is exactly what we have implemented the API for: To allow our customers to add custom functionality that we can't or do not want to implement into the standard product.

Please see my blog article for more information: "How We Rate Your Feature Requests" https://www.paessler.com/blog/2012/07/03/other/how-we-rate-your-feature-requests-company-culture-2