Another task I'm going to have in the near future... there is a hint in the release notes it's possible already, but I'm not sure:-

Create a heartbeat for activity in an organic group - including posts to the group etc.

I can't see an obvious way, at the moment. My thinking was just to create a views relationship to do something like join heartbeat_activity to og_ancestry on nid_target to nid and add where group_nid?

CommentFileSizeAuthor
#10 opportunity_heartbeat.txt4.9 KBbenoit.borrel
#10 heartbeat_views.views-og-relationship.patch592 bytesbenoit.borrel

Comments

Stalski’s picture

Stalski commented

Hey,

Yes, i saw two options to do this.
One was the way you speak off, to indeed use relations OR maybe even better in this context: views filter. Show only where nid_target is a node within group nid (the group node nid).

I think i will implement this in the upcoming two weeks.
Thx for your help!

Stalski

teleted’s picture

teleted commented

Stalski -- thanks for the excellent work on this module!

So, do I understand correctly that displaying heartbeats on a group homepage for just members and content of that group is currently not possible until you modify this module? Or is it possible if I properly set up a view?

ekes’s picture

ekes commented

My suggestion was as simple as:-

Index: views/heartbeat_views.views.inc
===================================================================
RCS file: /cvs/drupal-contrib/contributions/modules/heartbeat/views/Attic/heartbeat_views.views.inc,v
retrieving revision 1.1.2.2
diff -r1.1.2.2 heartbeat_views.views.inc
179a180,195
> 
>   if (module_exists('og_views')) {
>     $data['heartbeat_activity']['og_rel'] = array(
>       'group' => t('Heartbeat'),
>       'title' => t('Organic group'),
>       'help' => t('Create a relationship to nodes organic groups.'),
>       'relationship' => array(
>         'relationship table' => 'heartbeat_activity',
>         'relationship field' => 'nid_target',
>         'handler' => 'views_handler_relationship',
>         'base' => 'og_ancestry',
>         'base field' => 'nid',
>         'label' => t('Group'),
>       ),
>     );
>   }

I'm going to test it out for a bit now - not sure if it should be in hook_views_alter to make sure it gets called if og installed afterwards etc. It makes the relationship, and if you want to filter on a particular group you use the og_views parent group filter from this relation.

If all goes properly I'll post a proper patch.

Stalski’s picture

Stalski commented

Trying out everything, for the moment.
Please have a little more patience.

Stalski’s picture

Stalski commented

This relation does not what you want i think. a relation between the node posted to a group does not solve the problem of the where nid = the current group, or am I wrong?
could you describe or give me the sql you think would be correct for the organic group logic.
With a custom (or maybe later move to module) heartbeat access state object, it certainly is possible.

ekes’s picture

ekes commented

No it won't do anything about changes to the group node itself, be nice to have in addition (although most group sites I've worked with don't actually change the group node itself much). Membership changes would be the thing to add somehow.The above give a query like:-

SELECT heartbeat_activity.message_id AS message_id,
   heartbeat_activity.message AS heartbeat_activity_message,
   heartbeat_activity.timestamp AS heartbeat_activity_timestamp,
   DATE_FORMAT((FROM_UNIXTIME(heartbeat_activity.timestamp) + INTERVAL 7200 SECOND), '%Y%m%d') AS heartbeat_activity_timestamp_day,
   heartbeat_activity.uaid AS uaid,
   heartbeat_activity.uid AS uid,
   heartbeat_activity.uid_target AS uid_target,
   heartbeat_activity.nid_target AS nid_target,
   heartbeat_activity.access AS access,
   heartbeat_activity.message AS message,
   heartbeat_activity.message_concat AS message_concat,
   heartbeat_activity.timestamp AS timestamp,
   heartbeat_activity.language AS language,
   heartbeat_activity.variables AS variables,
   hid AS hid,
   concat_args AS concat_args,
   perms AS perms,
   custom AS custom,
   description AS description,
   attachments AS attachments
 FROM heartbeat_activity heartbeat_activity 
 INNER JOIN og_ancestry og_ancestry_heartbeat_activity ON heartbeat_activity.nid_target = og_ancestry_heartbeat_activity.nid
 WHERE og_ancestry_heartbeat_activity.group_nid = 190111
   ORDER BY heartbeat_activity_timestamp_day DESC

Thus you only get nodes in the group 190111 from the above.

Stalski’s picture

Stalski commented

Yes, indeed. That is if you choose the nid_target to be the "top group node id", isn't it?

I am writing down now all cases that can happen and I must say, it's rather difficult. Well with the grouping in mind ... . I will type it inhere, and if you like to follow my reason and maybe you can help me figure out the correct approach.

First of all: there are two approaches:

With group id
The query to run tries to do something with the top group id, but in this case, heartbeat logs must contain a variable like nid_target to map the top group id too. In this case the grouping will always go bad when grouping on users, because heartbeat can only group 1 variable for the moment (this will be fixed as well, i think).
E.g. "!user updated !article in !group" as single message will have these multipe message variable possibilities:

  • %user% group by node to summarize users makes no sense since author is mostly the same
  • group by users to summarize nodes with nid_target is group id
    - %group% will end up showing 1 title by same user in several groups. So here it is difficult, because the titles are different (more grouping variables would be needed).
    - %title% will end up showing several titles by same user for 1 group

With users (how heartbeat does things for the moment
The query to run only checks the currently logged in user (OR user from url). public, private and connected. So what can be done here is to make a additional AccessState class OgAccess.
In this case the additional sql would do something like 

   $sql = " AND (
     (ua.uid in( ". implode(',', $this->_heartbeatInfo->user_relations) ." ) AND ua.access >= 0 )
     OR (ua.uid_target = %d AND ua.nid_target <> 0 )
     )";

where $this->_heartbeatInfo->user_relations are all members of the current group node. In this case we fetch content via matching author in stead of trying to work with a match on group nid (heartbeat logs are not aware of that)

I will now type everything out more understandingly ;)

Stalski’s picture

Stalski commented
Assigned: Unassigned » Stalski
Status: Active » Fixed

I am closing this. So it is certainly possible now and there is an example on the demo site in about a week.
I am trying to cover lots of use cases there.
thx for the patch again Ekes

Stalski’s picture

Stalski commented
Status: Fixed » Closed (fixed)
benoit.borrel’s picture

benoit.borrel commented
StatusFileSize
new heartbeat_views.views-og-relationship.patch592 bytes
new opportunity_heartbeat.txt4.9 KB

Hi,

I wanted a view which displays a specific group activities, group context being passed as argument via URL. So, I:

  1. created a rule which logs group posts creation
  2. created a view (export enclosed)

But then I noticed the query generated by the view was not joining og_ancestry table properly. It was joining on heartbeat_activity.nid_target = og_ancestry_heartbeat_activity.nid instead of heartbeat_activity.nid = og_ancestry_heartbeat_activity.nid. So I altered views/heartbeat_views.view.inc::heartbeat_views_data() to fix the relationship with OG (patch enclosed).

Am I wrong or the relationship was indeed misdefined in heartbeat_views_data()?

benoit.borrel’s picture

benoit.borrel commented
Version: 6.x-4.x-dev » 6.x-4.11
rburgundy’s picture

rburgundy commented
Status: Closed (fixed) » Needs review

I think benoit.borrel meant to open this back up for discussion for his patch?

Regards

Stalski’s picture

Stalski commented
Status: Needs review » Fixed

Committed as a double. They both make sense in a way.

Usually the nid is the post and the nid_target is the group (join on nid_target)
But you can add a group, edit the group, join a group where the nid is thus the group (join on nid)
Or both.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.