Adding alarm comment using REST API

curl --location --request PATCH 'https://redacted/API/rest/v1/alarms/97848faf-dba3-4381-81aa-82828f16907a' \
--header 'Authorization: Bearer redacted' \
--header 'Content-Type: application/json' \
--data '{
    "priority": "34f1f987-6854-44fb-88a5-daa0add1e38a",
    "state": "60ab3977-090a-4381-a644-8bb51af2fdaa",
    "assignedTo.displayName": "some-value",
    "reasonForclosing": null,
    "comment": "test comment 1"
}'

Results in two entries appearing in the alarm’s activities section in Milestone XProtect Smart client: one with the comment and one indicating that assignee changed.

curl --location --request PATCH 'https://redacted/API/rest/v1/alarms/97848faf-dba3-4381-81aa-82828f16907a' \
--header 'Authorization: Bearer redacted' \
--header 'Content-Type: application/json' \
--data '{
    "priority": "34f1f987-6854-44fb-88a5-daa0add1e38a",
    "state": "60ab3977-090a-4381-a644-8bb51af2fdaa",
    "assignedTo.displayName": null,
    "reasonForclosing": null,
    "comment": "test comment 2"
}'

which unlike the previous one doesn’t specify assignee, but still specifies a comment, results in no new entries in the activities section.

Both requests return 202 Accepted.

Because the first one results in two entries, and one can add just a comment through Milestone XProtect Smart Client GUI, I expected to just be able to add a comment without having to modify other fields when using REST API. How do I accomplish this?

I am using version 2023R3

Hello Maciej,

Unfortunately, we have an issue with patching alarm through REST API request with null “assignedTo.displayName” value.

We’re going to fix it, but for now the workaround to update the comment for the alarm is to specify a non-null value in the “assignedTo.displayName” parameter.

Fixed in main branch. Now assignedTo.displayName accepts:

  • null - if value is not supposed to change
  • empty string - in order to un-assign alarm
  • non-empty string - in order to assign alarm to person

Would be available in 24 R2.