I tried to play a bit with notifications and I found one bug:
If “user A” creates a comment and makes a tag to user B in it (he puts @userB into this comment) but after sending it, he decides rather to delete this comment, then on user B side (in his account and Notifications center) there is a small blue number at Notifications (left menu), but in fact there is none. And even if he clicks on it and goes back, still the blue number does not disappear.
I think this should be fixed - at least the blue number should disappear after user B clocks on Notifications and clicks back. Or better, if user A deletes the comment, then no notification (no blue number) should be displayed in user B account Nitofication center.
@davide maybe a problem with the number that’s being calculated not applying a trashed
flag filter?
Hey @marcus,
I’ve explored the scenario you described. From my tests, notifications are marked as read once clicked, even if the associated comment has been deleted. In such cases, the mentioned user can still preview some content from the deleted comment.
To better understand your experience, could you share a short video or something demonstrating the issue?
I recognize that receiving a notification for a subsequently deleted message might be confusing. The thing is that, up to now, once a notification is sent, it remains visible to the user and we don’t have a mechanism to retract it yet. While this behavior isn’t technically a bug, I appreciate your perspective. I’ll discuss this with the team and keep you updated on any developments.
try to log in first as user A, put a comment and then delete it, and then log out and log in as user B. In this scenario I had (as a user B) the blue 1 in Notifications remained, it did not disappear.
I can confirm there’s something weird with the notification count and the notification panel when the user logs in. Thanks for reporting it.
I’ve opened an issue here: The notification count and the notification panel show wrong data when user logs in. (#2016) · Issues · Baserow / baserow · GitLab
I’ve also talked with the rest of the team, but we’re not planning to retract the notification once sent, for now. You can think about it more like an email, so that when it’s sent, the user will be able to see it, no matter what the author does with the original comment.
@marcus, the fix has been marged and it will part of the next release: Resolve "The notification count and the notification panel show wrong data when user logs in." (!1755) · Merge requests · Baserow / baserow · GitLab
I have a similar problem with notifications. It’s showing there are 2 even though nothing shows up when you click notifications. This happened after I permanently deleted a user.
Hi @deet,
did it happen just once after you log in with another user?
Could you please provide some more information about how I can replicate the bug?
@davide , ours might be harder to replicate. We originally had both traditional sign up and SSO. Then we restricted to only SSO. Someone with a legacy account realized they no longer had access. So I permanently deleted their legacy account as admin, then reinvited them. They signed in with SSO (which worked fine from their perspective). That is when I as admin noticed the ghost notification problem. Of note, the user had the same email for both login profiles (original and SSO).