[BUG]

[BusinessSteve]

Description:
Unable to make change to ticket company using logic very similar to the example code for closing all tickets with Nope!

To Reproduce
After connecting to the API:
#Get all tickets with the status "Waiting on Sales" and store as variable
$TicketsInWaitingSalesStatus = Get-AutotaskAPIResource -resource Tickets -SearchQuery '{"filter":[{"op":"eq","field":"CompanyID","value":"0"},{"op":"eq","field":"QueueID","Value":"29797118"},{"op":"eq","field":"Status","Value":"19"}]}'
#For each ticket stored in the variable, change the company ID
$TicketsInWaitingSalesStatus | ForEach-Object {$_.CompanyID = 1234567}
$TicketsInWaitingSalesStatus | Set-AutotaskAPIResource -Resource Tickets

Result is an error:
"Add-Member : Cannot add a member with the name "id" because a member with that name already exists...."

Expected behavior
Write the changes back to the API, with the only change being the company ID on each ticket

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Windows 11
• PowerShell version: V5.1
• Build 22621

[MichaelMcCool]

I am getting this too.

This bug was introduced in October 2021 in the Set-AutotaskAPIResource cmdlet.

        $MyBody = New-Object -TypeName PSObject
        if ($ID) {
            $MyBody | Add-Member -NotePropertyMembers @{id=$ID}
        }
        $PSBoundParameters.body.PSObject.properties | Where-Object {$null -ne $_.Value} | ForEach-Object {Add-Member -InputObject $MyBody -NotePropertyMembers @{$_.Name=$_.Value}}

The ID value is added manually, then again via $PSBoundParameters. Adding a -force parameter to the Add-Member section should allow this to be overwritten by the input object in cases where both an ID and input object's ID value are present.

[RickItum]

Anyone who's got a fix/workaround for this?

[TheMonzel]

@MichaelMcCool @KelvinTegelaar I got this as well. I thought about the reason for the current logical order. Wouldn't it make more sense to run the add section for $PSBoundParameters first - and use the manual add of $ID as some kind of optional overwrite? This would also prevent a -force attribute on every Add-Member of the $PSBoundParameters-line. Therefore I would suggest something like:

$MyBody = New-Object -TypeName PSObject
$PSBoundParameters.body.PSObject.properties | Where-Object {$null -ne $_.Value} | ForEach-Object {Add-Member -InputObject $MyBody -NotePropertyMembers @{$_.Name=$_.Value}}

if ($ID) {
  $MyBody | Add-Member -NotePropertyMembers @{id=$ID} -Force
}

if ($null -eq $MyBody.ID) {
  Write-Warning "Body must contain an ID." 
  break
}

[TheMonzel]

@KelvinTegelaar sure, you wanted this issue to be closed? This was not resolved yet.

[KelvinTegelaar]

Sorry, did a mass close, missed the ones that were supposed to stay open.

[TheMonzel]

@MichaelMcCool @KelvinTegelaar I got this as well. I thought about the reason for the current logical order. Wouldn't it make more sense to run the add section for $PSBoundParameters first - and use the manual add of $ID as some kind of optional overwrite? This would also prevent a -force attribute on every Add-Member of the $PSBoundParameters-line. Therefore I would suggest something like:

$MyBody = New-Object -TypeName PSObject
$PSBoundParameters.body.PSObject.properties | Where-Object {$null -ne $_.Value} | ForEach-Object {Add-Member -InputObject $MyBody -NotePropertyMembers @{$_.Name=$_.Value}}

if ($ID) {
  $MyBody | Add-Member -NotePropertyMembers @{id=$ID} -Force
}

if ($null -eq $MyBody.ID) {
  Write-Warning "Body must contain an ID." 
  break
}

If thats fine, I would just do a commit and open a pull request. I guess, this is more related to actual logic and how things should work, than the actual code.