Unread notification indicator stays ON after all notifs have been marked read

[labo-flg]

Description

When you mark all notifications as read, it launched a background task that ultimately change the read flag to all your notifications. When this task is done, the unread marker in the top right corner is still present.

Going to the notifs list and marking one of them unread, then read again, will make the marker disappear properly.

Environment

OCTI 5.12.15 (Testing)

Reproducible Steps

Steps to create the smallest reproducible scenario:

• have some unread notifs ; the unread marker should be visible

• select all notifs, mark them as read, launch the background task
• wait for completion
• all notifs should be marked as read in the list

Expected Output

Unread notification marker (red badge) should disappear.

Actual Output

Marker still present

Additional information

https://github.com/OpenCTI-Platform/opencti/assets/146674147/fd3ba404-41cd-42fd-9909-a43782351f3f

[Jipegien]

does not impact the data but make the feature useless.

[labo-flg]

RCA: when editing the status of individual notifs, the mutation in return can be used to update the global state of the notifications.

when changing notifs states from a background task, this is done... in background 🙃 The global state is not impacted in return of a BG task, this would actually be a new feature (significant work).

Note that refreshing the page would fetch the up-to-date notif status and remove the dot accordingly

[SamuelHassine]

This but need to be addressed as soon as possible @Kedae.

[Jipegien]

What is the status on this @labo-flg?

[labo-flg]

I did not have time to have a deep look at this issue.

To me, it's about knowing when a background task ends, to ultimately make the frontend refetch some query. I did not yet investigate how we could achieve that.

[labo-flg]

I have a draft of solution, I will push it for discussion.

The general idea is that background tasks just run actions on a set of elements. The Task Manager execute the action, and returns some errors if any. The actions are done using basic primitives like updateAttribute, but that's it. No contextual action is run additionally, like notifying the redis stream that notifications count might have changed for instance.

The problem is not only for notifications. If we defined subscriptions on some actions on the data elsewhere, they won't be notified on background tasks.

We need to implement this new mechanism inside the task manager : after executing the job, run some "subscription notification callback" depending on what has been updated and how.

[labo-flg]

The simplest solution would be to add an auto-refresh every N seconds, but this is not something we want, really. That's a lot of queries, in every screen (because on top bar), and 99% of the time it's useless.

After some discussions with @richard-julien and @Kedae, we advise to

1) lower the priority of this issue as a simple refresh of the page is a decent workaround, and we might have bigger fishes to care about for now 2) If this is something we want to do, design a proper solution (implies significant work) around a generic "platform event bus" on which the frontend could subscribe to (like "end of a bg task -> show a feedback, refetch a query, etc).

[labo-flg]

@nino-filigran @Jipegien happy to get your feedback on this one :)

[nino-filigran]

At some point, knowing when a task is finished and providing feedback to the user will be needed. This is quite a basic functionality (from a functional standpoint) that we should have (at least, in my opinion).

Additionally, when moving out of the screen (even though the notification is successfully marked as read through mass operation), the notification icon is still enabled, which is irritating. I thought that it would disappear, but users do have to fully refresh the page. Don't we have at least the possibility to have this behavior (and not being forced to refresh the page)?

[labo-flg]

at some point, knowing when a task is finished and providing feedback to the user will be needed.

Indeed it makes sense. That's the point of my suggestion, some sort of "platform event bus" on which the app registers and get real time feedback about background work. We can plan this for another milestone, happy to discuss it if it's on the table.

Don't we have at least the possibility to have this behavior (and not being forced to refresh the pa

The notification icon+badge is on the topbar. Navigating to another screen is optimized and does not reload the whole app, and the topbar is a stable element very high in the render tree. It's never "refreshed" actually. I'm afraid that's a totally different thing.

[nino-filigran]

Hmm then given your response it seems that we do not have any other choice but to schedule this in a future milestone. @Jipegien if it's ok with you, then we can plan it pretty quickly if possible, otherwise, we will have this behavior (basically not working functionality) for ages.

[Jipegien]

@nino-filigran can you study the opportunity to schedule this feature in 6.2 or 6.3 ?

[nino-filigran]

Let's add this to 6.3 for now, given the fact that 6.2 is already packed.

[Jipegien]

acceptable solution: refresh of the page after action