Create and/or edit NotificationActions

[paulkva]

Enhancement request: It would be helpful to have the ability to create (or at least clone and then edit) NotificationAction objects. I believe most of the necessary classes already exist, considering how GetNotificationAction() works.

[lordmilko]

Hi @paulkva,

Supporting the creation of additional object types (including Notification Actions) is something I've considered previously, however for most of these types (such as Schedules and Notification Actions) these aren't really objects that you have to create a lot of.

Are you able to advise what your use case is for creating Notification Actions? Why do you need to create so many that you need to automate it?

In regards to modifying properties, Notification Actions can be modified using the existing SetObjectProperty / SetObjectPropertyRaw methods.

Regards,
lordmilko

[paulkva]

Thanks for the quick reply! Admittedly, our use of PRTG might be a bit unusual. We're building a "democratized DevOps" system that allows individual engineering teams to own their entire application, including deployment and monitoring, and we'd like to give them the ability to receive PRTG notifications on an email address or Slack channel of their choice.

The total number we'd have to create won't be huge right now, but we're biased toward automating as much as possible in our efforts.

Since SetObjectProperty & SetObjectPropertyRaw work on NotificationActions, we could accomplish this automation if PrtgAPI would expose a generic CloneObject method.

[lordmilko]

Are you able to advise what you mean by expose a generic CloneObject method?

I was successfully able to clone a Notification Action using the following code

var newId = client.CloneObject(300, "test", -3);
var newAction = client.GetNotificationAction(newId);

-3 refers to the Notifications system object, which is the parent object of Notification Action objects. Instead of specifying a raw Notification Action ID to CloneObject you could instead pass a NotificationAction that was returned from GetNotificationActions()

You can identify the raw names of all Notification Action properties by modifying a Notification Action in the PRTG UI while monitoring with Fiddler. The Email property is called address_1.

[paulkva]

I ... can't believe I missed CloneObject in the docs. I'm sure I looked for it. My apologies. That's definitely enough of a workaround for our needs. Thanks!

I'll leave it up to you whether you'd like to close this or keep it as an open (lower priority) enhancement request.

[paulkva]

I just circled back to this and hit what looks like a known Paessler issue -- the one listed at the end of your 0.9.6 "Bugfixes" section. When I try code similar to your example above, I get back a newId of 3 which doesn't exist on my PRTG server. I can work around that by calling GetNotificationAction with a filter on the new object's name, rather than using the returned id.

It does seem to be creating the new NotificationAction objects though, so I still think I have everything I need to pursue the workaround. Thanks again!

[lordmilko]

I'm not sure how you're getting a newID of 3; when I do that against PRTG 19.2 with PrtgAPI 0.9.6 I get an ID of 2096; the known issue listed in the PrtgAPI 0.9.6 release notes should only apply to devices and groups; you will get a PrtgRequestException if the ID couldn't be resolved.

PrtgAPI extracts the ID of the cloned object from the response URL using the regular expression

(.+?id=)(\\d+)(&.*)?

I am a bit concerned that if you are getting a completely incorrect ID, that this expression is perhaps not working properly in all scenarios.

Are you potentially able to run Fiddler and advise what the returned URL of the clone request is? Alternatively, you can compile PrtgAPI from source and set a breakpoint and advise what the value of the decodedResponse value is?

[paulkva]

Ah, my code was still using PrtgAPI 0.9.3 when I posted my last comment; I've since updated to 0.9.6 and it's now returning the correct id. I think I might have misinterpreted your comment in the 0.9.6 release notes. My 2nd mistake on this issue in a week -- maybe I need a vacation? 😃

I captured traffic from Fiddler and saw this at the end of the response:
Location: /editnotification.htm?id=25078&tabid=3
I presume the regex was missing the first ? in the older version of PrtgAPI so it was finding tabid=3 instead of id=25078.

[lordmilko]

EDIT: nevermind, I see you noted that the issue was resolved in PrtgAPI 0.9.6. Yes, this would be related to the

Fixed CloneObject failing to parse ID of created sensors in PRTG 19.1

item in the release notes then. Previously the regex was too greedy (.+id= instead of .+?id=), matching the last instance of id=, which explains why it was previously returning the tabid of 3. While I had only observed this issue in relation to sensor objects, it appears it is a more general issue.

Are you able to confirm what version of PRTG you're using?

On my system (19.2.49.2018) the flow is as follows

Result	Request
302	/api/duplicateobject.htm?id=300&name=test&targetid=-3&username=prtgadmin&passhash=12345678
302	/editnotification.htm?id=2092&tabid=3
200	/public/login.htm?loginurl=%2Feditnotification.htm%3Fid%3D2092%26tabid%3D3&errorid=0

On my system I have two 302 redirects before I land on the /public/login.htm page which contains the id encoded under the loginurl property. This is consistent with the typical flow when cloning objects: PRTG attempts to open the cloned page, but because you're not logged in (since the PRTG API is stateless) you get redirected to the login page.

Are you potentially able to confirm whether your system does have this redirect to /public/login.htm after the request you posted?

[paulkva]

I discovered a couple interesting side effects yesterday.

First, the cloned object has the same permissions and ownership as the original object; the user who executes CloneObject doesn't necessarily have write permission. (I presume if the user didn't have read permission they couldn't even clone it.) That doesn't bother me much, now that I know to expect it.

Second and perhaps more importantly, GetObjectPropertiesRaw does not return the full set of NotificationAction properties if the user calling it only has read access. Looking at Fiddler, it appears that PrtgAPI is retrieving and scraping the settings page. For a read-write NotificationAction object, the page has all the form field names and values. For a read-only NotificationAction object, all the values are there, but pretty much only the active_## field names appear.

I realize I'm diving somewhat deeply into unsupported territory here, but would you like me to file either of these as separate issues? If nothing else, perhaps some caveats in the CloneObject and/or GetObjectPropertiesRaw documentation would be helpful.

[lordmilko]

GetObjectPropertiesRaw does not return the full set of NotificationAction properties if the user calling it only has read access

That is correct. As noted on the wiki:

Note due to the way PrtgAPI retrieves object properties, pluralized property methods (GetSensorProperties, etc) will throw an InvalidOperationException if the current PRTG user has read-only access to the specified object. Singular property methods (GetObjectProperty) can always be used regardless of whether the current user has read or write access.

The officially documented APIs for retrieving object properties only let you retrieve them one at a time, which is completely unacceptable. PrtgAPI does its best to workaround this to provide a coherent object model, however unfortunately there is only so much I can do with the facilities PRTG provides.

The user may not have write permissions to the object they are cloning, however they may have write permissions on the object they are cloning to. How the CloneObject cmdlet operates is out of PrtgAPI's control in this regard; it'll do whatever PRTG says it does.

[paulkva]

Ah but it didn't throw an InvalidOperationException, it retrieved a subset of the raw properties. Again, I realize NotificationAction objects are an unusual case, I just thought it was worth calling out.

[lordmilko]

Ah of course; GetObjectPropertiesRaw functions slightly differently to GetSensorProperties, et al. This is still the correct behavior (although I'm surprised it even returned anything at all). The usability of GetObjectPropertiesRaw on read-only objects should be better documented; I will update the wiki accordingly. Thanks!

It has also occurred to me that technically speaking there is no need to call GetObjectPropertiesRaw ever for NotificationAction objects, as PrtgAPI automatically does this for you to provide you with "enhanced" properties like the properties of all the notification action types (Email, SMS, EventLog, etc)