Challenge Displaying User Post on Other User Profile in Activity 2 View

The Activity record gets assigned to the user who performed the action -- in this case, the user who posted the status¹. Conventionally, it's not possible to get the listing you're asking in Activity. There is something called Realms though that's supposed to allow you to do something similar to this. Flag Friend implements a realm that's supposed to allow you to show the activity of people with whom you are friends. However, I haven't tested it, so I'm not sure if this makes it possible to provide a listing of a user's actions and the actions done to that user. Go to admin/settings/activity to enable realms.

If that doesn't work, this is really an issue for the Activity queue. The question is not specific to FBSS, but rather the question is whether it is possible to build a view of Activity messages from both actions by a certain user and actions done to that user. Another example of where this could be useful is the user reference fields for CCK, any of the modules that allow adding multiple authors to a node, PrivateMsg, or even comments on a user's node.

Let me know if you have any luck.

¹Actually, since you mention it, it does kind of make more sense to have the Activity record be assigned to the user who receives the message in the case of FBSS. Maybe I'll switch that, as it would seem to solve this problem.

Also--and this is not related to the issue, but it's something for you to keep in mind--Activity stores records historically. That means if a user writes a status, the exact text of the resulting Activity message at that time will get stored into the {activity_messages} table in the database. If a user edits or deletes the status later, the Activity message will still stick around with the same text that it had originally. (The same goes for everything else too -- nodes, comments, etc. -- but it's more noticeable with FBSS because usually the Activity message contains the whole status text [which is relatively likely to be changed] as opposed to a node title for example [which usually doesn't change].)

Yes, changing the user who is recorded into the Activity database will just switch the user with whom you're experiencing this problem, so it wouldn't really be a solution. Like I said though, realms might cover it.

In order for Activity records to be deleted at the same time as FBSS' records, something has to keep track of the association between them. I'm not sure, but I don't think that's possible at the moment; and besides, it would require another table in the database.

You're right that I've been a little frustrated with Activity, because some of its design decisions are not particularly compatible with the nature of FBSS. However, I'm going to continue to support it as much as I can. There's no need to explicitly support Heartbeat because Heartbeat relies on Rules, so FBSS' integration with Rules means that it also works with Heartbeat (or at least, it will once the Rules integration gets fixed...).

Sorry, just looked into it and it's not reasonable to change the active user because Activity uses the core Trigger system. If I switched it, users could end up with odd results like showing a "You posted on [user]'s profile" message to the recipient.

I don't really understand how realms are supposed to work in Activity right now, but I've been meaning to look into that because I'm hoping it will solve some of the conceptual barriers with FBSS. Otherwise, as I said in #2,

If that doesn't work, this is really an issue for the Activity queue. The question is not specific to FBSS, but rather the question is whether it is possible to build a view of Activity messages from both actions by a certain user and actions done to that user. Another example of where this could be useful is the user reference fields for CCK, any of the modules that allow adding multiple authors to a node, PrivateMsg, or even comments on a user's node.

Ya so this is must def doable with the Access side of things (realms).

In fact, you example of

even comments on a user's node

Is part of Activity2 core. See comment.activity.inc.

So just grab a hold of the Access side of the API (ref the Flag issue, Flag friend provides this, User Relationship patch).

You can also see this discussion here
#407840: hook_activity_grants() & hook_activity_access_grants()

Okay good, I was hoping for that. Thanks Scott. It'll be at least a week before I have time to look into this again but I will see what I can do when I get a chance.

From what I understand from reading the code in Activity itself, comment.activity.inc, the Flag Friend integration with Activity, and DEVELOPER.txt, grants and realms in Activity have to do with access to Activity records. What we're trying to do here is not related to access -- we want every user to be able to see all the activity that was directed to one user. In other words, there is an implied "recipient" of the actions here -- that is, there are two users involved, the "acting" user and the "acted upon" user -- and we want anyone to be able to see all the activity records for a given user regardless of whether the user in question was acting or acted upon.

Let's switch the analogy to comments for a second to see if that clarifies things.

Bob and Joe comment on a node that Susie created. Susie also comments on her own node. Susie and George comment on a node that Alex created. David is not friends with any of them, and has never posted a node or a comment. David goes to a view showing Susie's activity. What David expects to see is this:

Bob commented on Susie's node.
Joe commented on Susie's node.
Susie commented on her own node.
Susie commented on Alex's node.

To switch back to status updates, comments become status messages and nodes become the user's "wall":

Bob wrote a message on Susie's wall.
Joe wrote a message on Susie's wall.
Susie updated her status.
Susie wrote a message on Alex's wall.

From what I can tell -- and please correct me if I'm wrong, as I may have missed something -- that is not what access/grants/realms control.

So, Scott: do you understand what I'm trying to get at here? And is there any way to do this currently?

So ok fine I will tell you how to build that View if you will (the comment one, the status one still can't be built yet as its missing Activity Access implementation).

The important step, is to set the context for the Activity Access system. This is done through the argument Activity Access: Activity Context User. That is used to then set it so its Susie that is the Activity Access Context user. Then David will see Susie's activity just like he expects there based on Susie's Activity Access Grants.

That argument is of course optional, if not set it defaults to the logged in user.

Hope that helps.

@Scott, the problem is that from what I understand, for what you're describing to work, there would have to be an access grant to David. That's impractical because for each status created there would have to be an access grant for every user on the site. Is there something I'm missing here?

nope there is no access grant for david. You set the 'context' for the Activity Access system as Susie.

Re-read my comment, I understand completely, wouldn't build a system that foolish :-D

After discussion with Scott on IRC, I've just committed code that should make all this work. However, I'm having problems with my test site, so I couldn't confirm that it works beyond checking that it doesn't crash anything. If someone (pribeh?) could check it out, that would be greatly appreciated.

function facebook_status_activity_grants($activity, $object, $type) {
 return array(
   'facebook_status_owner' => array($object->uid),
   'facebook_status_poster' => array($object->pid),
 );
}

Unfort, that won't work with all activities. Its close, and flag_friend does something very similar but that is because with Flag Friend you want to save access control for EVERY Activity. With fb status, you only want to save access records for fb status messages.

That is why this is passed in the $type.

function facebook_status_activity_grants($activity, $object, $type) {
  $realms = array();
  if ($type == 'fb_status') {
     $realms['facebook_status_owner'] = array($object->uid);

     // No need to save both if they are equal. Just takes up more disk space.
     if ($object->pid != $object->uid) {
       $realms['facebook_status_poster'] = array($object->pid);
     }
   );
  }
  return $realms;
}

Another example can be found in comment.activity.inc, where it saves the comment access realm when the $activity has a nid.

Nice, thanks Scott, I committed the changes.

Presumably you should be adding the Activity Access: Activity Context User argument, not filters. You might need to remove the Node access: access filter as well. Other than that I'm not sure.

Do you have Activity Access Control enabled for FBSS at admin/settings/activity? The argument should be the only one under the group Activity Access...

Sweet, I'm glad it's working... Activity decided to stop showing any messages at all on my dev site even though they're recorded in the database, so I still haven't personally tested this. However, I probably just accidentally screwed with some files along the way, so I think this issue qualifies as fixed.

This issue prevents #408900: Rebuild Access table from landing. Basically, I want to remove $object and $type from the arguments to the hook_activity_grants().

I need to do this because the $object can't be stored in teh database for rebuilding. So is there anyway to get the pid without using the $object?

I mean, your question is essentially "Is it possible to read the object without having the object?" and the answer to that is "no." However, you could store the $object and $type in the $activity object before invoking hook_activity_grants(), which would be functional although probably confusing from a DX standpoint.

Nope the question is, "What is the db query to get the pid"

Ahh yep

$pid = db_result(db_query("SELECT pid FROM {facebook_status} WHERE sid = %d", $activity->eid));

function facebook_status_activity_grants($activity) {
  $realms = array();
  if ($activity->type == 'fb_status') {
     $realms['facebook_status_owner'] = array($activity->uid);

     // No need to save both if they are equal. Just takes up more disk space.
     $pid = db_result(db_query("SELECT pid FROM {facebook_status} WHERE sid = %d AND pid <> %d", $activity->eid, $activity->uid)); 
     if (!empty($pid)) {
       $realms['facebook_status_poster'] = array($pid);
     }
   );
  }
  return $realms;
}

?>

Does Activity currently do a query to get the object? If it does, then #31 is the correct solution, and I'll commit it ASAP.

Does Activity currently do a query to get the object?

You mean the eid? $activity in this (and EVERY case) is a row from the {activity} table. It is the atomic record.

I also want to get away from thinking about $activity has an $object. It doesn't, it has a set of $objects. Statement retracted. It has an object, thats what the eid field is for. (*sighs*)

I also like this particularly because it makes it clear on how to use the parts of the API. Access side deals only with every $activity record, it doesn't deal with $objects or $messages. Its crisp and clean separation that is important. And the benefit of this separation is to retroactively rebuild the {activity_access} table.

Unless sirkitree objects it will go in soon.

No, I mean currently the Activity module has to have some way to actually figure out what the $object is before passing it, right? It's not just passing an object that only contains the eid field or else the current facebook_status_activity_grants() wouldn't work. If getting the $object before calling module_invoke_all('activity_grants', $activity, $object, $type) involves at least one query, then it's worth using the code in #31. Otherwise the $object should be stored in the $activity record to reduce database calls.

No, I mean currently the Activity module has to have some way to actually figure out what the $object is before passing it, right?

O I see what your asking. The $object actually comes from the $context array from the trigger. Thats why, when the Trigger fires, the current code works, because it has an $object.

But now, we are writing grants at both Trigger firing, and when an admin clicks rebuild. So you can't always have an object.

Otherwise the $object should be stored in the $activity record to reduce database calls.

This is a bad design pattern as then you have to keep the object in-sync with the actual object. But to further the point, most (you are the only one that it isn't the case) modules don't care to much about the $object. What they care about is if $activity->nid exists, or setting grants for all $activity->uid's friends or something else about the $activity not the $object.

But you don't have to worry about performance. That little query uses the primary key so it examines exactly one row.

I committed it to Activity2 just now, so do please update. http://drupal.org/cvs?commit=299838

Committed.

Well, nothing in FBSS that should affect that changed. It's probably an Activity issue, although I'll let Scott confirm that before marking this fixed again. (Make sure you've refreshed your caches and such though.)

Well, I guess check the Activity queue first and see if anything similar has come up recently. If it hasn't, then I'll try to get ahold of Scott again and see if he can point me to where the problem might be. Unfortunately I have zero time this week and I'll be AFK for 5 days starting Wednesday next week so I won't be able to clean up the FBSS queue for a bit.

I'm not particularly motivated to work with Activity until there is a stable release of 2.x or one of the maintainers drops back in to help.

#725146: Fix Activity Integration