[buddypress-trac] [BuddyPress] #5148: Make notifications a separate component

buddypress-trac noreply at wordpress.org
Wed Nov 6 06:33:03 UTC 2013

#5148: Make notifications a separate component
 Reporter:  johnjamesjacoby       |       Owner:  johnjamesjacoby
     Type:  defect (bug)          |      Status:  new
 Priority:  normal                |   Milestone:  2.0
Component:  Notifications         |     Version:
 Severity:  normal                |  Resolution:
 Keywords:  needs-patch needs-ui  |

Comment (by johnjamesjacoby):

 Replying to [comment:9 henrywright]:
 > If notifications is to become a component, does that mean a dedicated
 notifications screen will be introduced? {{{
 members/username/notifications }}}
 Yes, exactly.

 > A standalone page (having lots more space than the drop-down) opens up
 the possibility of having a 'rich notifications' log such as
 > {{{ [avatar] member X followed you }}}
 > {{{ [avatar] member X replied to your comment }}}
 > There would be little need to 'dismiss' or delete a notification as the
 page could grow endlessly allowing the member to check back over old
 Correct. Notifications currently are always deleted, rather than mark
 `is_new` as `0`. My attached patch introduces logic for marking
 notifications as read/unread.

 > The log might grow big so notifications might need to be paged. So {{{
 bp_core_new_subnav_item() }}} might be needed.
 Attached patch introduces two notifications screens: Unread and Read. This
 should help with both the logging of events, and providing a more robust
 interface to see individual notifications, rather than lumping them all
 together like we do now.

 > Hopefully i'm not way off with my thoughts on this one. Just thought i'd
 throw an idea into the mixing pot.
 You're spot on with what's been in my imagination for a while now.

Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5148#comment:10>
BuddyPress <http://buddypress.org/>

More information about the buddypress-trac mailing list