[Bug] Marking an alert as read do not update it's "updatedAt" nor "updatedBy" field

[Dilaw9]

Request Type

Bug

Work Environment

TheHive 4.1.15

Problem Description

Marking as read an alert do not update its "updatedAt" nor "updatedBy" field when searching the alert with the /api/alert/_search API call.

Steps to Reproduce

1 - create an alert.
2 - mark it as read.
3 - search this same alert through the search panel of TheHive UI

Complementary information

This bug also impacts TheHive4py.api find_alerts() method as it also relies on the /api/alert/_search API call.

[To-om]

dupliates #2262

[Dilaw9]

Hi @To-om,

Thanks for your reply.

Though, I'm sorry I don't understand why this issue was closed as duplicate. It is not the exact same issue.
The issue I'm describing here is still existing in the latest release (4.1.15).

The "updatedAt" and"updatedBy" fields always have a "null" value even when the alert has been maked as read. This issue is visible when searching an alert with the /api/alert/_search API call. (With the search panel from TheHive Web UI or with the TheHive4py.api find_alerts() function for instance).

Edit to make the issue clearer :
The same alert will appear to have a correct "updatedAt" value when searched via the /api/v1/query?name=alerts API call but will have a "null" value when searched via the /api/alert/_search API call.

[To-om]

weird, I've just checked and I can't reproduce this behaviour.
How do you mark as read ? Using the web interface of TheHive ?

[Dilaw9]

Yes I mark as read via the web interface of TheHive.

Here are screenshots of the results I get:
Here I'm searching a specific alert (filtering with sourceRef) on the Alert panel of the Web interface:

And there I'm searching the same alert using the Search panel of the Web interface (selecting "Alert" search scope and filtering on sourceRef):

I have the same result when using find_alerts() function in TheHive4py.api.

As you can see, same alert object, but the updatedAt and updatedBy have a "null" value.

[To-om]

Thank you @Dilaw9 for this issue. It is now fixed.