[pull] master from KelvinTegelaar:master#146
Merged
pull[bot] merged 109 commits intoSEVENP:masterfrom Apr 24, 2026
Merged
Conversation
… matches the environment TenantID
Update the validation message for the snooze alert duration to reflect the new valid option of 90 days thats in the frontend.
CIPPCore Breakout into smaller modules and swap in some .net usage to improve file based action performance add validation to app manifest templates Update Push-AuditLogSearchCreation.ps1
…cripts (#1946) Coldstart performance improvements, test access permissions cache, list endpoints cache, minor pathing updates Tested in azure with no observed issues UI: KelvinTegelaar/CIPP#5687
Signed-off-by: Zacgoose <107489668+Zacgoose@users.noreply.github.com>
…ect wiring for audit log alerts Commit 94c0157 ("feat: Enhance security and functionality across multiple modules", 2026-03-19) introduced a CustomSubject lookup block in Invoke-CIPPWebhookProcessing with two compounding defects: 1. The lookup filters WebhookRules with PartitionKey='WebhookRule' (singular), but Invoke-AddAlert writes rules with PartitionKey='Webhookv2'. No writer anywhere populates the queried partition key, so the lookup always returns nothing. 2. The guard `if ($Data.CIPPRuleId)` depends on a field that is never set on matched records by Test-CIPPAuditLogRules. The if body never executes, so $WebhookRule is always $null. The same commit also changed the JSON template call from `-AlertComment $AlertComment` (working — parameter bound from the Test-CIPPAuditLogRules splat via $AuditLog.CIPPAlertComment) to `-AlertComment $WebhookRule.AlertComment`, which silently regressed AlertComment on webhook deliveries for the ~4 weeks since the commit landed. Email and PSA deliveries were unaffected because the HTML template call at line 116 still reads the correct $AlertComment function parameter. Fix: route CustomSubject through the same record-tagging mechanism that AlertComment uses. Test-CIPPAuditLogRules now tags each matched record with $item.CIPPCustomSubject = $clause.CustomSubject alongside the existing CIPPAction / CIPPClause / CIPPAlertComment tagging. The dead `if ($Data.CIPPRuleId)` lookup block in Invoke-CIPPWebhookProcessing is removed entirely. The JSON template call now reads AlertComment from the function parameter (reverting the regression) and CustomSubject from $Data.CIPPCustomSubject (the newly tagged field). No change to the HTML template call at line 116 — email and PSA continue to honor AlertComment via the function parameter as they did before, and CustomSubject on email/PSA is out of scope for this fix. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Commit 0d1f744 ("refactor: streamline user offboarding and improve task scheduling logic...", 2026-03-17) added a CustomSubject field to the ScheduledTasks row schema in Add-CIPPScheduledTask.ps1:203: CustomSubject = [string]$task.CustomSubject But the downstream consumer — Send-CIPPScheduledTaskAlert, invoked by Push-ExecScheduledCommand after an alert-type scheduled task runs — never reads it. Grep for CustomSubject in Send-CIPPScheduledTaskAlert returns zero matches. The title is built at line 125 with a hard-coded format: $title = "$TaskType - $TenantFilter - $($TaskInfo.Name)" Users who configured CustomSubject on scheduled tasks (including the hidden tasks that back scheduled alert functions) saw no effect on any delivery channel — email, webhook, and PSA all consume the same $title variable built here. Fix: check $TaskInfo.CustomSubject at title-build time and use it if set, falling back to the default format. No parameter plumbing needed since $TaskInfo is the full ScheduledTasks row, which now has the CustomSubject column thanks to 0d1f744. The Reference suffix logic is preserved and applied regardless of which title format is chosen. This is the sibling fix to c40194b which addresses the Path C-audit CustomSubject wiring. Together they complete the feature John Duprey staged in mid-March 2026 across two commits. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…p to c40194b) Commit c40194b added CIPPCustomSubject record-tagging in Test-CIPPAuditLogRules so the audit log rule's CustomSubject value would propagate to Invoke-CIPPWebhookProcessing for use in the JSON template title. The tagging line read $clause.CustomSubject: $item | Add-Member -NotePropertyName 'CIPPCustomSubject' \ -NotePropertyValue $clause.CustomSubject -Force \ -ErrorAction SilentlyContinue But the [PSCustomObject] projection upstream that builds $clause from $Config (the WebhookRules row) did not include CustomSubject in its field list — only AlertComment was projected from $Config. So $clause.CustomSubject was always $null, the tagging propagated null, and the webhook payload showed CIPPCustomSubject: null with the title falling through to the default operation-based generated title. Empirically observed in production at 2026-04-15 02:30:05 UTC after the c40194b deploy: an audit log rule with CustomSubject configured fired, AlertComment correctly appeared in the payload (the AlertComment projection was already present from before this work), but CIPPCustomSubject came through as null and the title was the default "<tenant> - New Rule Detected for <user>" instead of the configured "[TEST-BUG4-CS] Inbox Rule Detection". Fix: add `CustomSubject = $Config.CustomSubject` to the projection at lines 583-590 alongside the existing AlertComment line. One-line change. The downstream tagging from c40194b and the template parameter wiring at Invoke-CIPPWebhookProcessing.ps1:83 are both correct; this just completes the missing producer-side projection. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…p to 7f7e071) The c40194b + 7f7e071 fix pair was still incomplete because Test-CIPPAuditLogRules has TWO nested projections of the WebhookRules row, not one, and both must include CustomSubject for the value to reach the downstream tagging: 1. Upstream projection at lines 151-158 — builds $Configuration from the raw Get-CIPPAzDataTableEntity result, projecting $ConfigEntry into a pruned [pscustomobject] with only 6 fields (Tenants, Excluded, Conditions, Actions, LogType, AlertComment). This is the layer I missed in the first two fix attempts. 2. Downstream projection at lines 583-590 — builds $clause from $Configuration, projecting $Config into a per-clause object with 6 fields. The 7f7e071 commit added CustomSubject here. Commit c40194b added the tagging line at 650 reading $clause.CustomSubject. Commit 7f7e071 added the downstream projection line at 588. But the upstream projection at 157 was still dropping CustomSubject from $Config before the downstream projection could read it. AlertComment worked through both projections because it's explicitly listed in both layers (line 157 and line 587). The symmetric fix is to add CustomSubject to line 151-158 too. Production validation sequence that revealed this: - 2026-04-15 02:30:05 UTC: first test with c40194b only. CIPPCustomSubject came through as null. Root cause appeared to be missing downstream projection at lines 583-590. - 2026-04-15 13:00:03 UTC: second test with c40194b + 7f7e071. CIPPCustomSubject STILL came through as null. Diagnostic read of the WebhookRules row confirmed the row stores CustomSubject correctly. Diagnostic read of the file in the running container confirmed both previous fix lines are on disk. Diagnostic of $Configuration construction revealed the second nested projection that was missed. Lesson: when propagating a new field through a pipeline, trace the variable end-to-end from the original table read, not just from the consumption site. The "assume the projection is a complete copy" pattern bit this fix twice in a row. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Incorrect severity labels placed on logbook entries have been causing them not to send when configured on the Notifications tab
Enhance the `New-CIPPOneDriveShortCut` function to support custom URLs that point to specific document libraries and subfolders in SharePoint. This update allows users to create shortcuts not just for top-level sites but also for specific libraries and folders. Fixes KelvinTegelaar/CIPP#5892
- Add a alert entrypoint `Invoke-AddScriptedAlert.ps1` that handles multi-tenant and tenant group selections for Scripted CIPP Alerts - Expands any tenant groups via `Expand-CIPPTenantGroups` and merges them with individually selected tenants into a target domain list - Resolves KelvinTegelaar/CIPP#5833
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )