ConnectionRest - HTML Notification device type missing?

I'm wondering - is there any particular reason why notification devices of type 8 (HTML) are not implemented in the .NET REST API?

I've switched back to the source version, added it to the enum, made sure the proper uri is returned for the new type, and updated an Html device so at first glance there doesn't seem to be a reason to not support this.

Message was edited by: Stephan Steiner, added new info when I added the device type myself

looking on my 10.5 server I'm testing with now the UserTemplateHtmlDevice (template for the HTML notification device) is implemented and type 8 does look to be there under NotificationDevice.

I don't have my 10.0 server running but it all looks to be implemented in 10.5 at any rate - the wiki was updated with information on the HTML device templates and such:

http://docwiki.cisco.com/wiki/Cisco_Unity_Connection_Provisioning_Interface_%28CUPI%29_API_--_Index_of_All_CUPI_Documentation

Hmm.. I checked out the source maybe 3 hours ago.. and in ConnectionTypes.cs the NotificationDeviceTypes enum contains only

    public enum NotificationDeviceTypes

    {

        Fax = 3,

        Mp3 = 7,

        Pager = 2,

        Phone = 1,

        Sms = 6,

        Smtp = 4

    }

I added Html = 8, and then added the switch case in NotificationDevice.cs for (line 1585)

                case NotificationDeviceTypes.Html:

                    strUrl = string.Format("{0}users/{1}/notificationdevices/htmldevices/{2}", pConnectionServer.BaseUrl, pUserObjectId, pObjectId);

                    break;

That does take care of things. And I'm testing against an old CUCN - 9.1.2 (still waiting for my 10.0 license).

the .NET SDK is not tied directly to Connection's REST API work (i.e. when new properties/features get added to the REST API across versions the .NET SDK needs to be updated to handle them) - not everything the REST API can do is represented in the SDK (just most of the more important items or items my tools team needs to use) - so the authority on what the REST API can do is the WADL file and the /vmrest/schema page on the version of Connection you're testing.

As ever if there's something implemented in REST API that is not represented in the SDK you need, let us know and we add it to the to-do list...

I'd like my change to be included in future releases if possible so I can use the nuget variety. I doubt the SVN is write.. so, do you want diffs or is the above enough? And what's your contribution policy? I don't have anything right now that's missing (other than things that are actually missing in the vmrest API itself), but it seems perfectly doable to implement a new object when the need arises.

correct - I don't have it setup as a community-contribution project - too much overhead in the care and feeding (and testing) for that.  I just handle requests (like this one) as they come up.

I've already added the enum update above into the mainline I'm testing with now (along with the fixes for the deep copy "flag all" option from another thread).  I need to add more unit and integration tests (need to get total code coverage back up over %92 to keep management folks happy).  I'm also looking to add HTTP templates testing against 10.5 while I'm in here...

version 1.0.32 of the package was posted today - includes more unit tests, your changes above, updated JSON.NET version and some updates to the call handler owner functionality.

Umm... did something change again here in the latest lib? I had to extend my code and when I ran tests, my notification device update bombed out. I updated the source code from SVN and ran it instead of the nuget lib and found that in NotificationDevices.GetUrlPathForDeviceType you switch on pDeviceType and you don't handle the HTML device type. Yet, {0}users/{1}/notificationdevices/htmldevices/{2} is a valid path.

I quickly added another switch returning this path and all was well (thank god for the sources.. I have about 1 hour left to meet my deadline).

not sure where that rolled out - added it back in and am updating the integration tests to create/find/remove it.

again, will be there in 3.0.38