Skip to:
Content

BuddyPress.org

Opened 13 years ago

Closed 11 years ago

#574 closed defect (bug) (fixed)

Unread message numbers do not decrement in "My Messages" optionsbar

Reported by: jeffca's profile jeffca Owned by:
Milestone: 1.5 Priority: minor
Severity: Version:
Component: Core Keywords: has-patch commit
Cc: johnjamesjacoby

Description

From suggestion 2 on post: http://buddypress.org/forums/topic.php?id=1217

Unread message count stays the same after message has been opened.

Attachments (1)

574-1.diff (906 bytes) - added by boonebgorges 11 years ago.

Download all attachments as: .zip

Change History (14)

#1 @jeffca
13 years ago

  • Keywords unread count added; notification removed
  • Milestone Private Messaging 1.0 deleted

#2 @apeatling
13 years ago

  • Milestone set to Private Messaging 1.1

Not important enough for 1.0, moving this to 1.1.

#3 @(none)
13 years ago

  • Milestone Private Messaging 1.1 deleted

Milestone Private Messaging 1.1 deleted

#4 @apeatling
13 years ago

  • Milestone set to 1.1

#5 @apeatling
13 years ago

  • Milestone changed from 1.1 to 1.2

The count is only deprecated once the message has been opened, and is only reflected on the next page load. This will probably be fixed with AJAX, moving to 1.2.

#6 @johnjamesjacoby
12 years ago

Is it not possible to mark the message as read after we know which message it is but before the page loads and the count takes place?

#7 @johnjamesjacoby
12 years ago

  • Cc johnjamesjacoby added

#8 @apeatling
12 years ago

  • Keywords needs-patch added; unread message count removed
  • Milestone changed from 1.2 to 1.2.1

#9 @apeatling
12 years ago

This patch breaks posting to a group on the activity page.

#10 @boonebgorges
11 years ago

  • Component set to Core

jjj - the way things are currently set up, BP doesn't really 'know' what thread is being called up until the screen function is called up; the screen function, in turn, isn't defined until the parent item (the main Messages tab) and its name (eg Messages (2)) is already set.

Aside from completely rewriting the way that navs and subnavs register themselves, there are two strategies:
1) Reach into $bp->bp_nav and adjust the message count (after it's been registered but before it's been rendered). See 574-1.diff to see what this might look like.
2) Hook into the loading process *before* the messages nav is created with a function that checks to see (based on the action_variables etc) whether you're trying to view a single message, and if so it calls messages_mark_thread_read() on that thread.

Neither is great, but it strikes me that (1) has fewer potential problems (even though it's a bit uglier). I would rather not mess with load order if I can help it.

Thoughts?

@boonebgorges
11 years ago

#11 @boonebgorges
11 years ago

  • Keywords has-patch dev-feedback added; needs-patch removed

#12 @DJPaul
11 years ago

  • Keywords commit added; dev-feedback removed

The approach looks okay as an interim solution until bp_nav is overhauled.

#13 @boonebgorges
11 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [4266]) Decrement unread messages count before nav is rendered when reading a private message. Fixes #574

Note: See TracTickets for help on using tickets.