BP activity stream integration for create, edit, delete

[boonebgorges]

Should be group-aware, when appropriate.

When an item is connected with more than one group, I suggest we create separate items for each of those group. All will be 'hide_sitewide=true' except for the "primary" one, however we decide which one is primary. "Secondary" activity items should probably be marked as such, so that it'll later be possible to filter multiples from My Commons and other activity streams See http://redmine.gc.cuny.edu/issues/1237#note-11 for more thoughts about it, See also http://redmine.gc.cuny.edu/issues/3178#note-7 and note-8 for some discussion about how to do similar duplicate-hiding for crossposted forum posts.

@christianwach Can you take an initial look at this? @r-a-y If you have any brilliant ideas about the deduplication, please chime in.

[christianwach]

Gotcha

[boonebgorges]

@christianwach Have you had a chance to start looking at this? If not, may I steal it from you? :)

[christianwach]

Certainly, @boonebgorges, please do - I didn't count on the disruption of school holidays.

[boonebgorges]

Thanks, @christianwach.

81d3ac8 has the first part of the integration. Still to do:

• Better support for 'edit'. We should have a throttle to prevent stream flooding, and/or functionality that updates an existing activity item on multiple edits, rather than creating a new one. (Probably this: allow one "Boone edited the event..." item per hour/6-hour-period/day/whatever, with more frequent edits being ignored.)
• Activity action strings. I've done nothing here yet. Most of this is pretty simple, but there will have to be some magic to support strings of the form "Boone created an event in the groups foo, bar, and baz", especially when some of those groups are private/hidden and should not be visible to all users.
• 'delete' activity
• Duplicate hiding in My Commons and other combined activity streams (like My Groups). My current plan is to do something like this: at 'bp_before_activity_add_parse_args' (or whatever the filter is called :) ), do a pre-query to fetch the first 20 most recent activity items related to events. For each one, determine whether the user should see it: If it belongs to a group the user hasn't got access to, then no; if it is a duplicate of another one that will show up in the same stream, then no. Then compile the off-limits IDs and pass them to 'exclude'. Oy vey, but I don't see another way to do it. I'll implement aggressive caching where possible.

[r-a-y]

Let me know if this sounds insane for de-duplication.

• Record one activity item as the canonical event activity item. Add 'belongs_to_group' activity meta for each group to this item using bp_activity_add_meta(), so each meta item is separate.
• Manipulate the current group activity stream to add a filter query to match the 'belongs_to_group' activity meta key with the current group ID.
• For the sitewide activity page / My Commons, use a filter query / scope to match the 'belongs_to_group' activity meta key against the logged-in user's group IDs. For a user's page, use the displayed user's public group IDs.
• Somehow manipulate the Group Email Subscription plugin (GES) before email sending so it will use any activity item matching the 'belongs_to_group' meta key. Might be possible to fool GES on the 'bp_activity_after_save' hook before GES does its email sending routine.

[boonebgorges]

The way it's working out, the non-group-linked activity item ('component=events') will be the canonical one. The real problem is "mixed" activity queries - like My Commons and My Groups and the sitewide stream. In these queries, a non-canonical item may normally be slated to appear in the stream, but the user would not normally have access to the canonical one in that same stream. Say that Ray posts an activity item and connects it to A and B. Three activity items are created:

1. Ray created the event Foo (component=events)
2. Ray created the event Foo in the group A (component=groups, item_id=A)
3. Ray created the event Foo in the group B (component=groups, item_id=A)

On the sitewide activity stream, (1) will come through. If Ray is my friend, (1) will come through on My Friends and My Commons feeds. But (1) will never come through on My Groups. On My Groups, only (2) will naturally appear. And if someone else is in B but not A, then only (3) will appear for them. For any set of linked activity items, there's no way to guarantee that any specific one of them will appear on all activity streams where at least one of them appears.

For the first pass at this, I'm thinking about just forgetting about pagination/per_page. After the items are queried, look for dupes and remove them. Full stop. This may mean your per_page=20 request only gets you 18 or 15 items, but it's a heck of a lot easier.

[r-a-y]

But (1) will never come through on My Groups.

In my approach, we would filter the 'groups' activity scope to tack on the event activity item similar to what we did with friendship activity items and the 'just-me' activity scope. We wouldn't worry about recording multiple activity items for groups.

The only problem with this is GES, which relies on activity items recorded with the 'component' set to 'groups'. I think we can hack in before GES does its email sending to fake this behavior.

Another potential issue with my approach is with the 'hide_sitewide' visibility for the canonical event activity item when there is more than one group attached to an event. In this instance when a hidden group and a public group are attached to an event, we should probably set 'hide_sitewide' to 1.