ConnectionRest - FlagAllPropertiesForUpdate

Jeff

Thanks for implementing this. I've only just started using it, throwing out my own extension methods and I found a little snag... I'm rolling back a mailbox deletion which means restoring notification devices (amongst other things). As I get the standard notification devices from the template, rollback in this case means finding the proper notification device after restoring the box (that part works using the extensions you added last year), and then re-applying values that may be different.

Unfortunately, calling FlagAllPropertiesForUpdate on a notification device also flags the Conversation and DeviceName properties, both of which may not be modified. So, that in turn returns in CUCN throwing a 400 error telling me those fields may not be updated.

It's an easy fix on my end (just have to recompile and run my scenario again and I hope I'll be golden then), but probably requires another extension on the lib so that create and update have different extensions (and the update extensions would continue the foreach when PropertyInfo.CanWrite == false.

hmmm... I had thought I already accounted for that - it could be a larger issue where I have some properties not explicitly marked read only that need to be or maybe I just dreamed I'm smarter - I do that a lot.

I'll take a look next week and see...

just to follow up - yes, the deep copy method does check to be sure the properties being flagged are both readable and writable from a public interface - the issue with the notifcation device object was allowing the conversation name and device name to be editable.  The conversation name was originally supposed to be something that could be customized (think alternative conversations for the notification sequence to phones) but it was never implemented so the API locks it down. 

I have those items fixed - I'm adding some more unit and integration tests to the mix and I'll also look to add HTML templates to the mix - I'll post an updated version to NuGet this week and you should pick up the new version (or you can snag it from SVN as you've been doing).  I use NuGet for all my projects these days - it's handy.

Good to know - then I can rip out my modifications again. I had already swapped my SVN copy for nuget since that saves me from keeping a copy of the code I'm using but had to revert for these issues.

Speaking of Nuget, is there a particular reason your package imports an old version of json.net? It took some persuasion but I eventually got nuget to relent and allow me to update to the latest (and thus the same version I'm using whenever working with rest services in my other code).

interesting - the NuGet spec file is set to the _minimum_ version of JSON.NET it will accept but should always download the latest if you don't have one or accept any version (post 4.7) you might have installed.  I checked and it's definitely set to x>=4.x on that field.  You can even see it on the NuGet download page for the REST SDK it notes it as greater than or equal to.  The nuspec file format accounts for all kinds of options (ranges, minimum, maximum) and according to their docs minimum is supposed to grab the latest automatically.  It could be a major version thing (4.x vs. 6.x) - I'm not sure - I'll shoot them a message.

I'll roll it to be 6.0 minimum for the library when I post it later this week because I've been testing with it and being recent on the Json parsing library is a good thing.

updates are included in version 1.0.32 of the package - updated on NuGet and SVN today.

Just letting you know I upgraded and everything worked out just fine

Thanks.

cool, thanks for following up.

Still need to circle around on some 10.5 exposed features (templates) and the like when I get some time...

I started using CallHandlers.. and ran into another issue with rollback. I'm not sure if it is related to your library though. If you create a new callhandler, extract it, delete it, then try to recreate it based on what you previously extracted (and calling ClearPendingChanged followed by FlagAllPropertiesForUpdate, then this will never pass.

I had to remove the AfterMessageAction and AfterMessageTargetConversation from the ChangeList to get this working.

What I find curious is the AfterMessageTargetConversation.Ad... it seems my new Callhandlers always have this set, but it's not a valid value that you may set at any point - you can take an existing CallHandler and try to set its AfterMessageTargetConversation to Ad and it won't work either.. it returns an error about a table name containing conversation. But those properties are definitely not read only so here the trick with the read only properties won't work.

hmmm... Ad should be allowed (Alpha Directory - what we used to call name lookup handlers) - it has to be changed in conjunction with setting the target objectId to a valid directory handler or the update will fail - but I haven't tried that path in a while, I'll look at it in a bit and see if that's on my side or Connection's side...

sigh*

the Json parser is case insensitive so it reads it fine - but setting it requires "AD" instead of "Ad" or it'll fail.

I can quibble with the naming convention, but hey...

it'll also be fixed in 3.0.38.