Scope webhook source attribution to scheduler flow and rely on TaskInfo.Command fallback

[Copilot]

The issue was around mixed webhook payload shapes: some alerts (e.g., scheduled offboarding) already carry task command context, while others from scheduler notifications are generic log alerts. This change narrows source attribution behavior to those two realities without introducing broader schema passthrough logic.

• Scheduler webhook source propagation

  • Push-SchedulerCIPPNotifications now passes an explicit top-down source to webhook alerts via -WebhookSource $MyInvocation.MyCommand.Name.
  • This ensures generic scheduler log alerts are attributed to the invoking entrypoint, not inferred payload fields.

• Source resolution remains minimal and predictable in Send-CIPPAlert

  • Standardized webhook wrapping behavior is unchanged (New-CIPPWebhookRootSchema).
  • Existing fallback to TaskInfo.Command remains in place when no explicit WebhookSource is provided.
  • No additional branching for “already standardized” payload passthrough was retained.

• Resulting behavior

  • Scheduled task alerts (with TaskInfo.Command) keep command-based source fallback.
  • Scheduler generic log alerts use explicit top-down source from caller.

Send-CIPPAlert `
  -Type 'webhook' `
  -Title $WebhookTitle `
  -JSONContent $JSONContent `
  -TenantFilter $Tenant `
  -APIName 'Push-SchedulerCIPPNotifications' `
  -WebhookSource $MyInvocation.MyCommand.Name

Original prompt

#23
Can you please review this pr and rebuild it, it's overly complicated I think for something that should be simple enough to have a configuration endpoint and also a webhook standardised root schema

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Zacgoose]

@copilot we need the invoking alert/script name in the root object as well

[Copilot]

@copilot we need the invoking alert/script name in the root object as well

Implemented in commit 8c35d4b. The standardized webhook root object now includes a Source field populated from the invoking APIName (alert/script context), and tests were updated to verify it.