Add PolicyId output to Get-TeamViewerGroup function - #102
Conversation
AchilleasMitos-TV
left a comment
There was a problem hiding this comment.
Please also bump the minor version of the TeamViewerPS.psd1 as well as add an entry to the CHANGELOG for it.
| else { | ||
| Write-Output ($response.groups | ConvertTo-TeamViewerGroup) | ||
| $groups = @($response.groups | ConvertTo-TeamViewerGroup) | ||
| $groups | ForEach-Object { $_.PSObject.Properties.Remove('PolicyId') } |
There was a problem hiding this comment.
question: why don't we want the PolicyId field when requesting multiple groups?
There was a problem hiding this comment.
Well yes, this is very individual. Personally, I don't need this information in the all group output.
If you say you want it, I can remove my filter again.
I just wanted to keep the "general" output streamlined.
There was a problem hiding this comment.
Since the WebApi endpoint exposes it, I don't see a reason for not including it in the Powershell's response :)
AchilleasMitos-TV
left a comment
There was a problem hiding this comment.
Thank you for the improvement on the Cmdlet!
| else { | ||
| Write-Output ($response.groups | ConvertTo-TeamViewerGroup) | ||
| $groups = @($response.groups | ConvertTo-TeamViewerGroup) | ||
| $groups | ForEach-Object { $_.PSObject.Properties.Remove('PolicyId') } |
There was a problem hiding this comment.
Since the WebApi endpoint exposes it, I don't see a reason for not including it in the Powershell's response :)
|
I've incorporated all of your feedback in my last comit. Now it should be ready to merge. For the release process: Should I open an issue to request a release, or should I reach out to @ChristianJ-TV or @stefanhubertus directly (e.g. via E-Mail)? A contribution guide covering this would be helpful! Thanks for the review! |
|
@fs1n an email would do just fine :) As a last thing, please also make sure to clean up the git history appropriately. |
ea64b3a to
68e1bc5
Compare
|
Done. |
|
Thank you for the contribution, @fs1n! When we tried to prepare and plan a new release, we got blocked by the latest version of Pester which requires a few (small but impactful) changes. The PR to do that is now merged. Could you please rebase your branch to the current main and resolve the conflicts? If there are issues with the Pester test runs see this guide for further information: https://pester.dev/docs/migrations/v5-to-v6 Could you also add your changes to the unreleased list of 2.5.1? We are not yet sure which version the release actually will have, but we would put yours inside that, too. |
|
Hi @stefanhubertus |
Actually I meant 2.5.2, sorry for the typo/confusion 😅 Just add it to the latest, not released version in the changelog. |
68e1bc5 to
4e01850
Compare
|
@stefanhubertus Today, I found some other things I may want to contribute. As you don't seem to have a release cycle, can I expect another release in the near future for contributions? |
Summary
This PR adds the
PolicyIdfield to the output of theGet-TeamViewerGroupfunction. This enhancement enables retreival of the PolicyID, assigned to a group via theGet-TeamViewerGroup -Id <groupID>cmdlet.Changes
PolicyIdfield toGet-TeamViewerGroupcmdlet outputConvertTo-TeamViewerGroupconversion function to support the new fieldMotivation & Context
Being able to set an Policy to a group, I thought, "Why can't I retrieve it via the PowerShell module?" In a script that I had built, I had to use Invoke-RestMethod in the middle of the script, which is a bit of a maintenance pain. So I updated the module to make this output available too.
Checklist