feat(alerts): per-alert HaloPSA ticket priority - #193
Open
renada-jacob wants to merge 2 commits into
Open
Conversation
The HaloPSA integration has a single Default Priority that applies to every CIPP-generated ticket. This adds a per-alert override so a risky sign-in alert can open as P1 while a licence alert opens as P4. Mirrors the existing PsaTicketStrategy field - a dropdown on the alert wizard, stored on the alert row, read at send time - and covers both scripted and audit-log alerts. Priority only applies when a new ticket is created: when ConsolidateTickets appends a note to an existing ticket its priority is left alone, the same way tickettype_id is. Falls back to HaloPSA.DefaultPriority when the alert sets none, and to Halo's SLA default when neither is set, so existing alerts behave exactly as before. The dropdown loads its options at page level so the list is ready before the field is revealed, and when the configured Ticket Type has no priorities it is shown disabled with Halo's own explanation rather than as an empty box. Also wraps the HaloPSAFields lookups in @(). PowerShell unrolls single-element output, so a ticket type with one outcome - or any of these lookups returning a single explanatory row - serialised as a bare object instead of a list.
Halo priorities are defined per SLA - the same priority_id means a different thing under a different SLA. With no SLA on the configured ticket type there is nothing for the id to resolve against, so New-HaloPSATicket now omits priority_id entirely (per-alert override and integration default alike) and lets HaloPSA apply its own, instead of gambling on whichever SLA Halo picks at creation time. Note this also stops the integration-wide DefaultPriority being sent for SLA-less ticket types, which previously slipped through. The SLA resolution is shared between Get-HaloPriority and New-HaloPSATicket via a new Get-HaloTicketTypeSlaId helper, so the dropdown and the ticket writer cannot disagree about the same ticket type. The lookup only runs when there is a priority to send, so tickets without one cost no extra API call. On the alert page the priority field now stays visible but disabled when there is nothing to pick, showing Halo's own explanation of why and what happens to the tickets, and the priority list refreshes when stale instead of being cached until a hard reload.
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
#106 added a Default Priority to the HaloPSA integration, but it applies to every ticket CIPP raises. This adds one you can set per alert, so a risky sign-in alert can come in as Critical while a licence alert sits at Low.
It works like the PSA Ticket Strategy dropdown already on the alert wizard — set on the alert, stored on the alert row, read when the alert fires. Scripted and audit log alerts both covered. Left blank you get the integration default as now, and with neither set nothing is sent. Priority only applies when a new ticket is created; if ConsolidateTickets appends a note to an existing one, that ticket's priority is left alone, same as tickettype_id.
Halo priorities are defined per SLA, so the same priority id means something different under a different SLA. If the configured ticket type has no SLA there's nothing for it to resolve against, so no priority is sent and Halo applies its own. The dropdown says as much instead of showing an empty box:
Worth flagging for review: this also stops the integration-wide Default Priority being sent for ticket types with no SLA. #106 did send it and Halo resolved it against whichever SLA it picked at creation, which wasn't predictable, so I think this is right — but it is a change to what shipped.
Also wraps the HaloPSAFields lookups in @(). PowerShell unrolls single-element output, so a ticket type with one outcome came back as a bare object instead of a list.
Tested against a Halo sandbox with the integration default left empty, so anything landing on a ticket had to have come from the alert: the priority set on the alert lands on the ticket, blank falls back, and a bad value doesn't fail the ticket. Repeat alert appended a note and left the priority alone. Checked scheduled alerts both consolidated and split per user, and the audit log path. With a ticket type that has no SLA, no priority is sent.
Pester coverage for the priority resolution in New-HaloPSATicket, and extended the existing Test-CIPPAuditLogRules test for the audit log side.