Unread notification issue in BuddyPress 11.0.0-beta2

[niftythree]

Hello,

We upgraded BuddyPress from 10.6.0 to 11.0.0-beta2 for testing, and have noticed an issue with notifications.

Unread notifications will remain unread unless the bulk actions or "read" link is used to manually mark them as read. The number of notifications therefore also doesn't update unless these manual actions are completed.
If a message is read, its linked notification will move to "read" as it normally does.

Prior to installing 11.0.0-beta2, this wasn't an issue. After installing 11.0.0-beta2, the issue immediately occurs. When BuddyPress is rolled back, the issue remains unless it's rolled back until 10.2.0 or earlier. At 10.2.0 or earlier, notifications are read and the count updates appropriately. If the site is then upgraded back to 10.6.0 (or anything above 10.2.0), the issue returns.

We also tested this with different default themes to ensure the theme wasn't the issue. Initially when we activated Twenty Twenty-Three, the notifications worked as expected. However, when we activated other default themes (Twenty Twenty-Two, Twenty Twenty-One, Twenty Twenty and Twenty Nineteen), and when we reactivated Twenty Twenty-Three after this, the issue reappeared.

We're using the Legacy template and have tested this on a default install of BuddyPress with no other plugins running. We're not using any optimisation or caching.

Thanks.

[imath]

Hi thanks for testing 11.0-beta and for reporting this issue 👍.

Weird I haven’t noticed this so far. Is this concerning any notifications or a specific kind of notification ?

[niftythree]

Sorry for the delay, we were doing some additional testing. We believe this issue goes back to 10.3.0 after further testing (doesn't happen on 10.2.0 and is not related to version 11). We've been able to replicate it under the following circumstances.

When a private message is read, either through the messages page or notifications page, their status is updated as normal. However, once you mark a read notification as unread, and the message thread that notification is related to has already been read, the newly marked unread notification no longer updates to read when the text of the notification is clicked on. Bulk actions and using the Read/Unread link do not seem to be affected.

We also noted that if a notification is "stuck" as unread, and a user happens to mark its related message thread as unread, and then re-reads the message thread, the related notification(s) will also be marked as read.

We only normally use the Extended Profiles, Account Settings, Private Messaging and Notifications component. However, we have tested it with Friend Connections, Activity Streams and User Groups also enabled and their notifications seems to be working OK. It seems this is related only to Private Messages notifications.

Thanks.

[imath]

Ok I've been able to replicate. Everything works fine as long as you don't go to the read view of the user's notification screen to mark unread a message. In this case going back to the message view is not marking the notification as read.

It's possibly related to [13270]

Trac ticket: ​https://buddypress.trac.wordpress.org/ticket/8778

[imath]

@niftythree could you check the ​PR is fixing the issue?

[niftythree]

Thanks for looking into it, @imath. Unfortunately, we haven't had any luck getting it to work.

[imath]

This is weird. It fixed the issue for me 😕

[niftythree]

Hi @imath. We've tried it again, but still weren't able to get it to work. Not sure if our testing environment is set-up as needed, though. Might be worth getting another opinion? Sorry we couldn’t help further. 🙁

[imath]

Thanks @niftythree for trying again. It made me look deeper into the issue and understand why it wasn't solved for you and why I thought it was solved for me.

On my testing I was always testing the first message of the thread which is the thread ID. But when you are testing another message of the thread it was failing. I've updated the PR and this time I believe it should really fix the issue, no matter which message of the thread was unread before viewing the thread.

Could you test one last time the ​updated PR ?

[niftythree]

Hi @imath,

This fix seems to have helped, but we think we've worked out why we were getting different results before.

If a user's oldest notification has never been opened, and they then open newer notifications and mark these as unread, the "marked unread" notifications will never be read when clicked on. The user must read the oldest (never read) notification first.

In addition to this, if the user had marked multiple notifications as unread, only clicking on the oldest "marked unread" notification will result in the notification being marked as read. If any other "marked unread" notification in the list is clicked on, it won't work. The user has to do this for all "marked unread" notifications in the list (i.e. click on the oldest notification), including if any notifications are deleted (except for the oldest).

We'd always been testing with a user who had a large number of notifications, and it was only when we marked them all as read that the current fix worked, prompting us to look more closely at the older notifications.

Thanks. 🙂

[imath]

All these notifications are always about Private Messages?

[imath]

@niftythree

Ok I think I know why this was happening. I believe the updated PR should really fix the issue 😅 🤞.

See ​https://github.com/buddypress/buddypress/pull/43

[niftythree]

Hi @imath,

From our testing, the new changes seem to have fixed the issue. 🙂

Thank you.

[imath]

Awesome 😎 Many thanks to you! Thanks to your tests I was able to find the right fix 🤝. I’ll commit the PR shortly.

[imath]

In 13383:

Improve consistency between private message status & notification

A private message can have a status set to read or unread by the user. When the Notifications component is active, a notification is generated each time a message is sent. When the user opens this message, 2 actions are performed:

1. Set the message status as read.
2. Mark the notification about this message as read.

When opening a message, even if the message has a read status, we still need to check if there's an existing notification about it as notifications can be marked unread from the user's notifications screen. If it's the case, then we need to make sure to mark this unread notification as read 🤪.

Props niftythree

Closes ​https://github.com/buddypress/buddypress/pull/43
See #8778 (trunk)

[imath]

In 13384:

Improve consistency between private message status & notification

A private message can have a status set to read or unread by the user. When the Notifications component is active, a notification is generated each time a message is sent. When the user opens this message, 2 actions are performed:

1. Set the message status as read.
2. Mark the notification about this message as read.

When opening a message, even if the message has a read status, we still need to check if there's an existing notification about it as notifications can be marked unread from the user's notifications screen. If it's the case, then we need to make sure to mark this unread notification as read 🤪.

Props niftythree

Fixes #8778 (branch 10.0)