Skip to:
Content

Opened 10 years ago

Closed 8 years ago

#574 closed defect (bug) (fixed)

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

Reported by: 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 8 years ago.

Download all attachments as: .zip

Change History (14)

#1 @jeffca
10 years ago

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

#2 @apeatling
10 years ago

  • Milestone set to Private Messaging 1.1

Not important enough for 1.0, moving this to 1.1.

#3 @(none)
10 years ago

  • Milestone Private Messaging 1.1 deleted

Milestone Private Messaging 1.1 deleted

#4 @apeatling
10 years ago

  • Milestone set to 1.1

#5 @apeatling
10 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
9 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
9 years ago

  • Cc johnjamesjacoby added

#8 @apeatling
9 years ago

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

#9 @apeatling
9 years ago

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

#10 @boonebgorges
8 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
8 years ago

#11 @boonebgorges
8 years ago

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

#12 @DJPaul
8 years ago

  • Keywords commit added; dev-feedback removed

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

#13 @boonebgorges
8 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.