Microsoft Teams Provider: Support Dynamic Parameters - Part 5 #2533

Prerequisites

• This issue has an informative and human-readable title.
• Assignee should meet with issue author before starting work.

💡 Summary

Update the Teams provider and its directly related helpers to support schema-driven parameter values.

Motivation and context

Teams uses multiple APIs with different environment and authentication capabilities. Shared configuration should remove duplication without obscuring those differences.

Part 1 (#2196) establishes shared configuration accessors, but application code still contains independent configuration values. Use [ScubaConfig] accessors for environment validation, defaults, and product metadata where applicable. Preserve Graph authentication, permission requirements, and provider output. Keep API-specific restrictions explicit.

Implementation notes

Use the existing accessors in
ScubaConfig.psm1 instead of recreating product lists, environment lists, or report-name mappings.

These are static methods on [ScubaConfig]. Configuration JSON now lives under PowerShell/ScubaGear/schemas:

• ScubaConfigSchema.json defines accepted values and product metadata.
• ScubaConfigDefaults.json defines canonical products and configuration defaults.

For a provider directly under Modules/Providers, import the class at the beginning of the module:

using module '..\ScubaConfig\ScubaConfig.psm1'

Adjust the relative path for nested helper modules. Modules or test scopes that execute validation expressions referencing [ScubaConfig] may need their own using module; importing the class elsewhere is not always sufficient.

For product parameters, choose the accessor according to the input contract:

• Use GetSupportedProducts() when only canonical product identifiers are valid.
• Use GetAllValidProductNames() at boundaries that accept aliases or *.
• Expand * and normalize aliases before passing products to code that requires
  canonical identifiers. Accepted input values are not all executable products.

Replace fixed environment validation with (example):

[Parameter(Mandatory = $true|$false)]
[ValidateScript({ $_ -in [ScubaConfig]::GetAllValidProductNames() })]
[string[]]
$ProductNames = [ScubaConfig]::ScubaDefault('DefaultProductNames'),

[Parameter(Mandatory = $true|$false)]
[ValidateNotNullOrEmpty()]
[ValidateScript({ $_ -in [ScubaConfig]::GetSupportedEnvironments() })]
[string]$M365Environment

Use -cin where the previous validation was case-sensitive. Use -in where it was case-insensitive. Preserve mandatory flags, parameter sets, defaults, and null/empty validation unless a separate behavior change is explicitly required.

Acceptance criteria

• Existing provider tests pass without weakening assertions or removing coverage.
• Invalid inputs fail before authentication or network calls.
• Case sensitivity is preserved and tested if needed.
• Aliases and wildcard handling are tested where supported.
• Unsupported provider/environment combinations are handled explicitly.
• A test changes metadata in memory and proves the implementation reads it dynamically (eg. Intune).
• Tests restore modified metadata and configuration state after execution.
• Unit tests mock cloud calls; live-tenant checks are reported separately.
• Module import works from outside the repository in Windows PowerShell 5.1.
• Argument completion returns the expected schema-driven values where applicable.
• Provider output remains compatible with existing Rego and reporting consumers.
• Relevant PowerShell tests, lint checks, and affected Rego tests pass.
• No stale references to the former configuration JSON locations remain.
• All Smoke Tests pass
• All Functional Test pass