[pull] dev from KelvinTegelaar:dev#1059
Merged
Merged
Conversation
Updated to write to and read from cetralised CIPP database
Added license check for new Defender category Signed-off-by: DamienMatthys <damien@pcunplug.com>
Cleaned up logging Signed-off-by: DamienMatthys <damien@pcunplug.com>
…enant.ps1 Remove old sync function Signed-off-by: DamienMatthys <damien@pcunplug.com>
Remove old sync schedule Signed-off-by: DamienMatthys <damien@pcunplug.com>
Fixed sync to add one CVE per Device Signed-off-by: DamienMatthys <damien@pcunplug.com>
Add severity and resolvingComment to the incident PATCH so users can reprioritise and document why an incident was resolved. Build the body as a hashtable/JSON so free-text comments with quotes are escaped, and gate assignee changes behind an explicit AssignToSelf flag so status and severity and status edits no longer clobber the existing owner.
The generated openapi.json types every request body but leaves each 200
response as the generic StandardResults envelope, and carries no operationId
on any operation. That makes the spec hard to consume: OpenAPI importers that
key on operationId skip every operation, and downstream tools get no typed
output fields to map against.
This adds a deterministic post-processing stage that enriches the generated
spec without replacing the upstream generator:
- operationId injection: bare endpoint name per operation, method-prefixed
only where a single path carries multiple methods. Existing operationIds are
preserved; collisions are a hard failure.
- typed 200 responses: derived from two checked-in sources, the frontend shape
baselines (Tests/Shapes/*.json) and page simpleColumns declarations. The
{ Results, Metadata } envelope is preserved as the API actually returns it.
The enriched spec is published as the openapi.enriched.json asset on each
GitHub Release. A PR check workflow runs the test suite and strictly lints the
enriched spec against a committed ignore-baseline that pins pre-existing
upstream findings, so any new finding fails CI.
Pure function of the two repositories; same input produces byte-identical
output. Stage and runner are PowerShell with a Pester suite (50 tests).
Add ExcludeGroupIds and AssignmentDirection so exclude groups are targeted by ID and a Replace edits only one direction, preserving the other plus All Users/All Devices. Exclude-only requests no longer error or wipe assignments, and exclusion targets drop the settings block that Graph rejects.
…vanced) Get-CIPPAlertCheckExtension reads a per-tenant watermark from the AlertLastRun table to only fetch alerts newer than the previous run, but never wrote it back. So $Since always fell back to the default 24h window and the same alerts were re-sent on every scheduled run. Capture the run start, read/store an explicit LastRunTime watermark (falling back to the existing Timestamp for compatibility), and upsert it after processing so each run only sends alerts created since the last run. Fixes #6216
The detection script of a Win32 Custom Application was base64-encoded from the raw input, so %tenantid% and other Get-CIPPTextReplacement tokens were not resolved (they reached Intune as literal text), unlike the install and uninstall scripts. Run the detection script through Get-CIPPTextReplacement first, matching the install/uninstall handling. Fixes KelvinTegelaar/CIPP#6226
…vanced) (#2114) ## What The "Check" add-in's alerts are re-sent on every scheduled run - each run dumps the whole recent backlog to the configured webhook instead of only new alerts. Reported in #6216 (e.g. 13 test alerts resulted in 13 entries on every run). ## Cause `Get-CIPPAlertCheckExtension` reads a per-tenant watermark from the `AlertLastRun` table (`PartitionKey 'AlertLastRun'`, `RowKey "<tenant>-Get-CIPPAlertCheckExtension"`) so it only fetches alerts newer than the previous run - but it never writes that watermark back. As a result `$Since` always falls back to the default 24-hour window, so every run re-fetches and re-sends the same alerts (and the day-partitioned de-dupe in `Write-AlertTrace` resets at midnight, which lines up with the reported timing jumps). ## Fix Capture the run start, read/store an explicit `LastRunTime` watermark (falling back to the existing `Timestamp` for backward compatibility), and upsert the `AlertLastRun` row after processing. Each run now only sends alerts created since the previous run. ## Testing - PowerShell parses clean. - A mock-storage harness confirms the behaviour: run 1 sends the backlog, run 2 (no new alerts) sends nothing, run 3 sends only a newly-added alert. Fixes KelvinTegelaar/CIPP#6216
# Resolve tenant variables in the Win32 Custom App detection script Fixes KelvinTegelaar/CIPP#6226. `%tenantid%` and the other `Get-CIPPTextReplacement` tokens resolve in a Win32 Custom Application's install and uninstall scripts, but not in the detection script, which reaches Intune with the literal `%tenantid%` string. In `Add-CIPPW32ScriptApplication.ps1` the install and uninstall scripts are passed through `Get-CIPPTextReplacement` before being base64-encoded, but the detection script was encoded from the raw `$Properties.detectionScript`. This change runs the detection script through `Get-CIPPTextReplacement` first, the same way as the install and uninstall scripts directly below it. Verified against the real `Get-CIPPTextReplacement` with mocked tenant lookups: before the change the detection script keeps the literal `%tenantid%`; after, it resolves to the tenant's customerId and matches what the install script produces. Other tokens such as `%tenantfilter%` resolve too.
Improve logging and error handling in the GDAP relationship termination function
…2112) ## What Adds a deterministic post-processing stage that enriches the generated `openapi.json` with typed `200` response schemas and a unique `operationId` per operation, and publishes the result as a Release asset. It does **not** replace the existing generator; it runs on its output. ## Why The generated spec types request bodies but leaves every `200` response as the generic `StandardResults` envelope, and carries no `operationId` on any operation. Two practical consequences: - OpenAPI importers that key on `operationId` skip every operation. Tested against a real importer: the unmodified spec imported as **0** actions; with `operationId` injected it imports as **all 582**. - Downstream tools get no typed output fields to map against. ## How A PowerShell stage (`.build/Add-OpenApiResponseSchemas.ps1`) with two passes, both pure functions of checked-in sources (no live API calls, byte-identical output across runs): - **operationId**: bare endpoint name per operation; method-prefixed only where one path carries multiple methods (e.g. `GetExecCSPLicense` / `PostExecCSPLicense`). Existing `operationId`s are preserved; any collision is a hard failure. - **typed 200 responses**: derived from the frontend shape baselines (`Tests/Shapes/*.json`) and page `simpleColumns` declarations. The `{ Results, Metadata }` envelope is preserved exactly as the API returns it (no flattening, so the schema stays truthful to the wire). Endpoints with no typed source keep `StandardResults`, which is correct for write/exec operations. ## Publishing + CI - `openapi-enriched-release.yml` builds and uploads `openapi.enriched.json` as an asset on each GitHub Release (no commits back to the tree). - `openapi-enriched-check.yml` runs the test suite and **strictly lints the enriched spec** against a committed ignore-baseline (`.redocly.lint-ignore.yaml`) that pins pre-existing findings, so any *new* finding fails CI. - `.github/workflows/` is gitignored in this repo (the existing workflows are force-added), so these two were added with `git add -f`, matching the repo convention. ## Tests 50 Pester tests + PSScriptAnalyzer (0 findings), run via `Tests/Build/Invoke-BuildTests.ps1`. Covers operationId rules (bare/disambiguated/preserve/collision-throws), response typing, idempotency, and the frontend-scan edge cases. ## Known limitations (documented in `.build/README.md`) - Only `get/post/put/patch/delete` are processed (the spec has no other methods today). - Paths are assumed to start with `/api/` (all current paths do). - A typed `200` replaces the existing `200.content` (today only `StandardResults` exists there). - Conditional/ternary `simpleColumns` expressions are intentionally not parsed (a conservative miss is preferred over capturing non-column strings). ## Side benefit Injecting `operationId` also removes the `operation-operationId` lint warning that previously applied to every operation in the spec. ## CI activation note Both workflows are guarded with `if: github.repository_owner == 'KelvinTegelaar'`, matching the convention of the existing workflows in this repo (forks do not run them). As a result they will **not** appear as status checks on this PR from the fork; they activate once merged into the upstream tree. Verification was therefore done locally before opening this PR: - `Tests/Build/Invoke-BuildTests.ps1`: 50 Pester tests passing, PSScriptAnalyzer 0 findings - strict Redocly lint of the generated `openapi.enriched.json`: 0 errors, 0 warnings, 5 pre-existing findings ignored via the committed baseline; verified to fail on an injected new finding - both workflow YAML files parse clean - enrichment is deterministic: same inputs produce byte-identical output across runs
This pull request enhances the `Push-BECRun` PowerShell function by adding the retrieval and logging of sent message traces for a user, and includes this data in the output object. These changes improve the auditing and incident response capabilities of the function by providing more comprehensive information about user activity. **Enhancements to auditing and user activity tracking:** * Added retrieval of sent message traces using the `Get-MessageTraceV2` cmdlet, with error handling and logging in case of failures. The trace includes message details such as status, subject, recipient, received time, and sender IP. * Included the collected sent message trace data as a new property (`SentMessages`) in the output object returned by the function.
Introduce support for ExcludeGroupIds and ExcludeGroupNames in assignment functions. Frontend PR: KelvinTegelaar/CIPP#6244
Overhaul of the rather interesting way to construct a JSON payload and add in severity and resolving comment functionality. Frontend PR: KelvinTegelaar/CIPP#6234
Updated to write to and read from cetralised CIPP database
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.
7 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 : )