Cut 5073 migrate jumpcloud power shell modules to use specific endpoints

[shashisinghjc]

Issues

CUT-5073 - Migrate JumpCloud Powershell modules to use type-specific endpoints

What does this solve?

It ensures the module supports the new Shared Groups feature and aligns with backend API changes, while maintaining backward compatibility and encouraging users to upgrade to newer module versions.

Is there anything particularly tricky?

NA

How should this be tested?

Verify that the PowerShell module uses the new type-specific group cmdlets instead of the generic Get-JCGroup. Test by retrieving groups using Get-JCSystemGroup, Get-JCUserGroup, and Get-JCPolicyGroup to confirm they return expected results without errors. Validate getting groups by ID and filters, creating a new group, and removing a group. Ensure functionality works correctly and no calls are made to the deprecated /api/v2/groups endpoint.

Screenshots

---

Note

Medium Risk
Moderate risk because group and policy-group retrieval/membership now routes to new type-specific v2 endpoints and replaces legacy policy-group implementations, which could impact scripts relying on previous parameters/response shapes.

Overview
Updates the PowerShell module to support type-specific group APIs by adding new SDK-backed cmdlets for System, User, and Policy groups (including policy-group CRUD and membership management) and exporting them in JumpCloud.psd1 (bumping version to 3.1.0).

Enhances Get-JCGroup and Get-DynamicHash to handle Policy groups and to query the dedicated endpoints (/api/v2/usergroups, /api/v2/systemgroups, /api/v2/policygroups) with stricter case-sensitive name lookups, while removing the older custom Policies/PolicyGroups implementations.

Refreshes DirectoryInsights help text/links and adds/updates Pester coverage for the new group and policy-group cmdlets, plus minor test parameter cleanups and changelog updates.

^{Written by Cursor Bugbot for commit fd197c3. This will update automatically on new commits. Configure here.}

[cursor]

Documentation links point to feature branch not master

Low Severity

The .Link URLs in Get-JCEvent.ps1 and Get-JCEventCount.ps1 were changed from pointing to master branch to CUT-4981_v2EUSupport, a feature branch. This appears to be an accidental commit from SDK generation and will produce broken documentation links once the feature branch is deleted.

Additional Locations (1)

• [PowerShell/JumpCloud Module/Public/DirectoryInsights/Get-JCEventCount.ps1#L43-L44](https://github.com/TheJumpCloud/support/blob/7d7cb51eab0ec0f78ca93193391ce45eb2847891/PowerShell/JumpCloud Module/Public/DirectoryInsights/Get-JCEventCount.ps1#L43-L44)

 

[jworkmanjc]

Okay Hey @shashisinghjc I've not done a good job writing this card.

You've solved the first aspect of this card, gone above and solved the second aspect but we already have a set of Get/Set/Remove-JCPolicyGroup cmdlets in our module which is my mistake adding them.

What I want us to do is this. You've done what was asked in the card. Let's merge 80% of this into a new release branch for 3.1.0. I'm looking at the difference between the Auto-Generated SDK functions in the PWSH Module and what I wrote for policy groups. There's a few things I think we can take from both.

My aim with the PWSH module was to provide admins with the easiest way of interacting with our API possible. SDKs are autogenerated and do not include quality of life things like searching by name. I'll create another card for this, but I'd like to add a new parameter to our auto-generated functions for searching by Name, then we can bring in these new functions you've added to the module.

Today we've got the function Get-JCPolicyGroup which has parameters for ID and Name. You can specify something like Get-JCPolicyGroup -id 671a7433adf66800018e38da or Get-JCPolicyGroup -name "Windows Update"
to get the same result.

The autogenerated SDK function brought in has the SDK parameters for filter/ fields/ sort. Which are missing from my handwritten function. My aim would be to bridge these in another card.

Let's do this.

• Remove the Auto-Generated Policy functions, these exist in Public/Policies/PolicyGroups
• Retain the new functions Get-JCSystemGroup.ps1, Get-JCUserGroup.ps1
• Retain changes to Get-JCGroup.ps1
• I'll create a new card to modify the jcapiToSupportSync.ps1 function to:
  • automatically add a new "Name" parameter to generated functions
  • Generate new functions for:
    • Get/Set/Remove-JCSystemGroup
    • Get/Set/Remove-JCUserGroup
    • Get/Set/Remove-JCPolicyGroup

If we auto generate those functions, we'll get the latest changes from our SDKs, but still retain the ability to search for groups by "Name" which is the case for the current Get-JCPolicyGroup function. IMO we can merge this into a release branch without getting all tests to pass, you've done 99% of the work here given my poor planning I don't need to hold it up since we can't go live with it yet.

[cursor]

Cursor Bugbot has reviewed your changes and found 4 potential issues.

[cursor]

Tests use nonexistent -PolicyGroupID parameter on new cmdlets

High Severity

The new SDK-based Remove-JCPolicyGroup only accepts -Id, -InputObject, and -PassThru, but tests pass -PolicyGroupID and -Force (which don't exist). Similarly, Get-JCPolicyGroup only accepts -Id, not -PolicyGroupID. Since these cmdlets use [CmdletBinding()], PowerShell will throw a parameter-binding error at runtime. This affects AfterAll cleanup blocks, meaning test resources will be orphaned, and multiple test cases will fail.

Additional Locations (2)

• [PowerShell/JumpCloud Module/Tests/Public/Groups/PolicyGroups/Get-JcPolicyGroup.Tests.ps1#L16-L17](https://github.com/TheJumpCloud/support/blob/5b4ad5c94347d27353c41d45659948e68a2af723/PowerShell/JumpCloud Module/Tests/Public/Groups/PolicyGroups/Get-JcPolicyGroup.Tests.ps1#L16-L17)
• [PowerShell/JumpCloud Module/Tests/Public/Groups/Get-JCGroup.Tests.ps1#L37-L38](https://github.com/TheJumpCloud/support/blob/5b4ad5c94347d27353c41d45659948e68a2af723/PowerShell/JumpCloud Module/Tests/Public/Groups/Get-JCGroup.Tests.ps1#L37-L38)

 

[cursor]

Tests use nonexistent -Name parameter on Get-JCPolicyGroup

High Severity

The new SDK-based Get-JCPolicyGroup accepts -Id, -InputObject, -Fields, -Filter, and -Sort — but not -Name. Tests call Get-JCPolicyGroup -Name $TestGroupName which will throw a parameter-binding error. Lookup by name now requires -Filter "name:eq:$TestGroupName" instead.

Additional Locations (1)

• [PowerShell/JumpCloud Module/Tests/Public/Groups/PolicyGroups/New-JcPolicyGroup.Tests.ps1#L2-L3](https://github.com/TheJumpCloud/support/blob/5b4ad5c94347d27353c41d45659948e68a2af723/PowerShell/JumpCloud Module/Tests/Public/Groups/PolicyGroups/New-JcPolicyGroup.Tests.ps1#L2-L3)

 

[cursor]

Set-JCPolicyGroup exported but implementation file deleted

Medium Severity

Set-JCPolicyGroup is still listed in FunctionsToExport at line 105, but its implementation file (Public/Policies/PolicyGroups/Set-JCPolicyGroup.ps1) was deleted in this PR and no replacement was added. Users calling Set-JCPolicyGroup will get a "command not found" error. It needs to be removed from the exports list.