Enable tab completion support for -include parameter

[davidhaymond]

Is your feature request related to a problem? Please describe.
The -include parameter on the various Get-ITGlue**** cmdlets don't offer any tab completion.

Describe the solution you'd like
I want tab completion to work when using -include so I know what values are available.

Describe alternatives you've considered
N/A

Additional context
N/A

[Celerium]

I noticed this while writing the help descriptions and as an assumption, I think I can see why they are like this. As an example check out the configurations "Index" & "Show" endpoints.

Both have a -include parameter but depending on which endpoint you use accept different values.

• Maybe use two different parameter names?
• Maybe dynamic parameters could help?

Index
adapters_resources, configuration_interfaces, rmm_records, passwords, attachments, tickets, user_resource_accesses, group_resource_accesses

Show
adapters_resources, configuration_interfaces, rmm_records, rmm_adapters_resources, passwords, attachments, tickets, adapters_resources_errors, rmm_adapters_resources_errors, active_network_glue_network_devices, to_configuration_connections, from_configuration_connections, user_resource_accesses, group_resource_accesses, recent_versions, related_items, authorized_users

[davidhaymond]

Ah, that makes sense now.

A third option would be to simply include all possible values for Index and Show, as a typing aid. On one hand, this might wrongly imply that any allowed value would work for any endpoint, but on the other hand, with the current system, the user can type anything, which of course isn't guaranteed to work either.

[Celerium]

I'm not the biggest fan and or even very knowledgeable when it comes to dynamic parameters as they feel very bloated and can be difficult to decipher but here is a snippet of a recent project where I used them.

PokeDexAPI

    DynamicParam {
        $ParameterName = 'slug'
        $RuntimeParameterDictionary = New-Object System.Management.Automation.RuntimeDefinedParameterDictionary
        $AttributeCollection = New-Object System.Collections.ObjectModel.Collection[System.Attribute]
        $ParameterAttribute = New-Object System.Management.Automation.ParameterAttribute
        $ParameterAttribute.Mandatory = $false
        $AttributeCollection.Add($ParameterAttribute)

        if($PsCmdlet.ParameterSetName -eq 'indexByPokemon'){
            $ValidateNotNullOrEmptyAttribute = New-Object System.Management.Automation.ValidateNotNullOrEmptyAttribute
            $AttributeCollection.Add($ValidateNotNullOrEmptyAttribute)

            $RuntimeParameter = New-Object System.Management.Automation.RuntimeDefinedParameter($ParameterName, [string[]], $AttributeCollection)
            $RuntimeParameterDictionary.Add($ParameterName, $RuntimeParameter)
            return $RuntimeParameterDictionary
        }
        elseif ($PsCmdlet.ParameterSetName -eq 'indexByEvolutionStones' -or $PsCmdlet.ParameterSetName -eq 'indexByLeagues'){
            switch ($PsCmdlet.ParameterSetName) {
                'indexByEvolutionStones'	{ $ValidateSet = 'Fire', 'Water', 'Thunder', 'Leaf', 'Moon', 'Sun', 'Shiny', 'Dusk', 'Dawn', 'Ice'}
                'indexByLeagues'	        { $ValidateSet = 'Indigo', 'Johto', 'Hoenn', 'Sinnoh', 'Unova', 'Kalos', 'Orange'}
            }
            $ValidateSetAttribute = New-Object System.Management.Automation.ValidateSetAttribute($ValidateSet)
            $AttributeCollection.Add($ValidateSetAttribute)

            $RuntimeParameter = New-Object System.Management.Automation.RuntimeDefinedParameter($ParameterName, [string[]], $AttributeCollection)
            $RuntimeParameterDictionary.Add($ParameterName, $RuntimeParameter)
            return $RuntimeParameterDictionary
        }
        else{$null}
    }

[davidhaymond]

@Celerium I've used dynamic parameters once, to allow for a dynamic ValidateSet (I wanted to read the set of allowed values from a config file instead of hardcoding them in the script).

I agree that they are convoluted, and should only be used when necessary. Once of the biggest downsides is that they don't appear in the built-in help (in the generated cmdlet syntax), so they can be hard to discover. The behavior of a dynamic parameter (allowed values changing depending on what other parameters are present) might also confuse the user.

For these reasons, I'm not really a fan of using dynamic parameters here just to get 100% accurate validation. I think just listing all possible values in a ValidateSet is probably close enough.

[Celerium]

Good point I forgot they don't appear in the about_help. I'm good with adding them all into a ValidateSet and just noting the about_help which ones can be used with what parameter set.