Handling Case Id Pararameter
Opened this issue · 7 comments
Lr API will accept either the case number or case id when requesting an endpoint about a case.
So far, I've just included $Id
as a generic System.Object
for case functions, and check for either a valid guid
or int
with Test-LrCaseIdFormat
. I'd like to have the option of passing the case id through the pipeline, however.
We run into issues when using the pipeline, however.
If you use both ValueFromPipeline
and ValueFromPipelineByPropertyName
, neither work properly, because the parameter type is System.Object
, so PowerShell binds the value itself (the entire case object) to the $Id
parameter.
- When using
ValueFromPipeline
we can only do:
PS> 2068 | Get-LrCasePlaybooks
PS> "0ECC5442-919C-4D7C-8162-D0BCC689642B" | Get-LrCasePlaybooks
- When using
ValueFromPipelineByPropertyName
we can do:
PS> Get-LrCaseById -Id 2068 | Get-LrCasePlaybooks
Options
-
(Bad) Separate parameter
$Id
into$Id
and$Number
, which will be aguid
andint
, respectively. Each should then be capable of supporting both pipeline options. This messes up the validation, however. We can't make both mandatory, and if we use a parameter set, passing a case object will mess that up (by giving both at the same time). -
(Meh) Only implement one:
ValueFromPipeline
orValueFromPipelineByPropertyName
. We would need to decide which scenario above would be the most common use case: passing a case object, or passing only an int/guid. -
(Bad) Remove pipeline support.
-
(???) Only implement support for case
guid
OR casenumber
. Not sure this is desirable?
Other ideas?
Separating the parameters, $IdNumber and $Guid would not be terrible. Guid is stronger than IdNumber, as IdNumber will always need to be converted to Guid. We can make them mandatory but not as per the [Mandatory] option, but instead validate that one of those two parameters is not null. If we find both are null then we throw an argument exception specifying to provide IdNumber or Guid.
Not the best, but I think in this type of situation would be the ideal standardization across these functions.
IdNumber will always need to be converted to Guid.
In general, you can use either the case number
or the case guid
interchangeably, particularly when the case identifier is specified in the url path - the API will happily accept either.
Are there use cases you can think of where we can only use the case guid and not the number? You've worked on some parts of the API that I haven't in the module, so if you've seen that it would help me to think through this.
Hi - Im not sure if this is the right section to post this question, please let me know if I should post this somewhere else. I am running into the following issue, I am trying to loop through all the case IDs off a csv file with the following script, but no cases are updated,
ForEach ($a in (Get-Content "C:\Users\userX\Documents\SmartResponse.Framework-master\cases4.csv")) {Update-LrCaseStatus -Credential $token -Id $a -Status 2}
I am able to successfully update a case status when I enter its case ID in this format: Update-LrCaseStatus -Credential $token -Id 123-456-789 -Status 2
Hey @peruvianjc, what's the format of your case IDs in the csv file? 1234 or the 123-456-789?
Revisiting this, ultimately we should establish our own schema to map these to due to parameter name re-use as you go from Case to Playbook to Procedure.
Immediately, I would move to the LogRhythm structure of Id = GUID and Number = CaseNumber. We can validate if Id is GUID, if not, is it INT? if not, is it String? and perform validation based on that.
Sample logic:
# Test CaseID Format
$IdFormat = Test-LrCaseIdFormat $Id
if ($IdFormat.IsGuid -eq $True) {
# Lookup case by GUID
try {
$Case = Get-LrCaseById -Id $Id
} catch {
$PSCmdlet.ThrowTerminatingError($PSItem)
}
# Set CaseNum
$CaseNumber = $Case.number
} elseif(($IdFormat.IsGuid -eq $False) -and ($IdFormat.ISValid -eq $true)) {
# Lookup case by Number
try {
$Case = Get-LrCaseById -Id $Id
} catch {
$PSCmdlet.ThrowTerminatingError($PSItem)
}
# Set CaseNum
$CaseNumber = $Case.number
} else {
# Lookup case by Name
try {
$Case = Get-LrCases -Name $Id -Exact
} catch {
$PSCmdlet.ThrowTerminatingError($PSItem)
}
# Set CaseNum
$CaseNumber = $Case.number
}
Results:
Get-LrCasePlaybooks -Id "408C2E88-2E5D-4DA5-90FE-9F4D63B5B709"
id : 409D10D8-0C79-4D44-B999-CC2F6358B254
name : New Playbook
description : Its pretty good.
originalPlaybookId : EB042520-5EEA-4CE5-9AF5-3A05EFD9BC88
dateAdded : 2020-06-07T13:30:04.0997958Z
dateUpdated : 2020-06-07T13:30:04.0997958Z
lastUpdatedBy : @{number=-100; name=LogRhythm Administrator; disabled=False}
pinned : False
datePinned :
procedures : @{total=0; notCompleted=0; completed=0; skipped=0; pastDue=0}
PS N:\Projects\git\SmartResponse.Framework> Get-LrCasePlaybooks -Id 2
name : New Playbook
description : Its pretty good.
originalPlaybookId : EB042520-5EEA-4CE5-9AF5-3A05EFD9BC88
dateAdded : 2020-06-07T13:30:04.0997958Z
dateUpdated : 2020-06-07T13:30:04.0997958Z
lastUpdatedBy : @{number=-100; name=LogRhythm Administrator; disabled=False}
pinned : False
datePinned :
procedures : @{total=0; notCompleted=0; completed=0; skipped=0; pastDue=0}
PS N:\Projects\git\SmartResponse.Framework> Get-LrCasePlaybooks -Id "Case 2"
id : 409D10D8-0C79-4D44-B999-CC2F6358B254
name : New Playbook
description : Its pretty good.
originalPlaybookId : EB042520-5EEA-4CE5-9AF5-3A05EFD9BC88
dateAdded : 2020-06-07T13:30:04.0997958Z
dateUpdated : 2020-06-07T13:30:04.0997958Z
lastUpdatedBy : @{number=-100; name=LogRhythm Administrator; disabled=False}
pinned : False
datePinned :
procedures : @{total=0; notCompleted=0; completed=0; skipped=0; pastDue=0}
@Jt3kt - we discussed this again recently. Assigning to you, but we should discuss and come up with a solid plan together.