Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No good way of emptying/clearing an attribute value #21

Closed
Identitry opened this issue Feb 22, 2018 · 4 comments
Closed

No good way of emptying/clearing an attribute value #21

Identitry opened this issue Feb 22, 2018 · 4 comments

Comments

@Identitry
Copy link

Identitry commented Feb 22, 2018

Hi!
Struggeling with the problem that there's no good way of clearing an attribute value against Skype for Business. Currently we need to be able to clear ConferencingPolicy to use the default policy and LineURI for making a phonenumbers available to someone else.

Tried flowing empty string but the import will return null so empty string is flowed again. Also tried flowing Null() (Allow Null values checked) but that doesn't clear the attribute value.

What are your recommendations for clearing attribute values or is this something you have foreseen?

@NileshGhodekar
Copy link
Contributor

If you look at the code in the Export script, currently, it will not clear the LineURI so only update with something else will work. Also looking at the code it should be able to clear ConferencingPolicy. What are the exact cmdlets to fire to clear these? May be we need a bit of revision to the code.

@Identitry
Copy link
Author

I checked out the Invoke-SetCsUserCommand function and it contains really bad coding practices, the option of flowing Null has defenately been foreseen.
To start with, there is no reason what so ever building the command as a string for calling Invoke-Expression, splatting the parameters to the command would be far better and it would allow flowing null values.

As a quick fix for being able to clear the LineUri was to change this line that currently doesn't accept flowing null:
if ($lineURI -ne $null) { $cmd += " -LineURI '$lineURI'" }
...into:
if ($null -eq $lineURI) {$cmd += ' -LineURI $null'}else{ $cmd += " -LineURI '$lineURI'"}

The function Invoke-GrantCsPolicyCommands has an equally crappy implementation, string commands created and executed with Invoke-Command. For example if passing a null value using Invoke-Expression and this line:
if ($conferencingPolicyChanged) { $cmd += " | Grant-CsConferencingPolicy -PolicyName '$conferencingPolicy' -PassThru" }
...Will result in this when flowing Null:
Grant-CsConferencingPolicy -PolicyName '' -PassThru
...and not:
Grant-CsConferencingPolicy -PolicyName $null -PassThru
...We already have a fix for this and that was to add the default policy as a named policy and flow the name of that policy however that was before I realized these functions has such a crappy implementation.

Flowing null as ConferencingPolicy will of course give us an "exported-change-not-reimported" warning since the import will return an empty string and not Null however the biggest problem is that and empty string probably wont enable the default Policy.

I think both of these methods needs to be fixed with better coding practices and the possibility to flow null values where allowed.

@NileshGhodekar
Copy link
Contributor

@Identitry, the current coding style is due to two design goals: 1. The codebase when written was meant for PowerShell 2.0, no splatting there. The other goal was to be able to debug on demand in a live production environment what exact command is being executed hence the creation of string first. You simply turn debugging on or on via the sync config file as and when there is a need for troubleshooting. Lot of things have changed over the years. Now the PowerShell connector shipped with the product works with .NET 4.5 and so supports PowerShell 3.0+, so you are welcome to upgrade the scripts with PowerShell 3.0+ capabilities as long as we can also meet the second goal as well. Let me know if you sign up for this and I'll add you as a contributor to the project, else I'll just close this issue now that you quick-fixed it for yourself.

@NileshGhodekar
Copy link
Contributor

Hi, I'm closing this issue as waiting for someone to invest their time to do script upgrade to PSH 3.0 and beyond if they are strongly convinced that there is definite ROI on this effort.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants