You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When broken notifications (with missing resources) are fetched but not displayed to the user, the unread counter counts them even if they are not displayed. That leads to a negative behavior where 1 notification is displayed but the counter consistently shows more and the user is unable to react in any way.
To Reproduce
Steps to reproduce the behavior:
Publish a callout
Notification is received automatically
Delete the callout
The notification is not displayed but still counted as unread
Expected behavior
Notifications that are not displayed must not be counted as unread.
Screenshots
Areas that will be affected
The text was updated successfully, but these errors were encountered:
I am starting to believe that the server must know about how and when each notification type can break and filter it out / delete it.
Many more potential issues will arise with the new additions
Currently, the client handles broken notifications in the notification's view component by excluding them from the render.
The badge is controlled by the initial count of unseen notifications. Conceptually the client shouldn't apply additional logic. As Svetlio suggested, it's better to be filtered on the server.
Describe the bug
When broken notifications (with missing resources) are fetched but not displayed to the user, the unread counter counts them even if they are not displayed. That leads to a negative behavior where 1 notification is displayed but the counter consistently shows more and the user is unable to react in any way.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Notifications that are not displayed must not be counted as unread.
Screenshots
Areas that will be affected
The text was updated successfully, but these errors were encountered: