[buddypress-trac] [BuddyPress] #1046: Need to differentiate the component action "new_wire_post"

buddypress-trac at lists.automattic.com buddypress-trac at lists.automattic.com
Sat Sep 19 23:00:09 UTC 2009

#1046: Need to differentiate the component action "new_wire_post"
Reporter:  jeffsayre  |       Owner:  jeffsayre
    Type:  defect     |      Status:  new      
Priority:  major      |   Milestone:  1.1      
Keywords:             |  
 Currently, the component action "new_wire_post" can be associated with
 either xprofile or with groups activity. This is not only too generic of a
 description for the action, but also makes it difficult for my Privacy
 Component to properly differentiate between xprofile and groups wire post
 activity items.

 My component creates one new table. The table has a component name field.
 This field is central in helping to differentiate which component objects
 the user has set to be filtered for privacy. All activity objects have a
 component name of activity (see screen capture of table schema and sample

 Unfortunately, with both xprofile and groups writing the same component
 action for wire post activities, it is impossible to tell whether a
 privacy record for an activity record that has a component action equal to
 new_wire_post is intended to be used for xprofile or groups privacy

 I does not make any sense to create an additional field in the privacy
 table to help differentiate between these two identical terms. There is
 already a component name field that is properly being used to associate
 the privacy filter type with the component and its object that needs to be

 So, I propose changing the "new_wire_post" component action for xprofile
 to "new_profile_wire_post" and the "new_wire_post" component action for
 groups to "new_group_wire_post".

 The patches necessary for this change are included.

 Doing so will cause problems with activity stream deletion functions as
 any data written to the table prior to this change will have the old
 component action of "new_wire_post" and not the new actions. So, either a
 function that runs a SQL update will need to be included or the activity
 deletion functions will have to use an if statement, checking for both the
 old and the new.

Ticket URL: <http://trac.buddypress.org/ticket/1046>
BuddyPress <http://buddypress.org/>

More information about the buddypress-trac mailing list