User opt out of activity recordings

Moving this into 2.x branch. What needs to happen is a drupal_alter() right after we build all the access records but before we add them to the query. What this allows is some module to do just what is described. It can alter out things that don't belong. Whether it be all 'og' access types, remove all activity messages for a certain user. Crazy-ness can ensue :-D

Here is how you make it work for D6 2.x

Index: activity.module
--- activity.module
+++ activity.module
@@ -368,7 +368,9 @@ function _activity_access_sql($access_table_alias, $account) {
   foreach (module_implements('activity_access_grants') as $module) {
     $grants[$module] = module_invoke($module, 'activity_access_grants', $account);
   }
-
+  
+  drupal_alter('activity_access_records', $grants);
+  
   // construct the SQL
   foreach ($grants as $module => $values) {
     if (!empty($values)) {

What that does is allow another module to remove grant records. So its real easy to write a module that allows users to pick people to ignore from their activity stream. It also makes it possible for a module to allow users to say "Don't show my activity in anyones feed" And any and all combination inbetween.

review it plz

with this patch it becomes really easy to write in a module that says "only friends actions go into the feed"

function my_module_activity_access_records(&$grants) {
  $friend_module = 'my_friend_module';
  foreach ($grants as $module => $values) {
    if ($module !== $friend_module) {
      unset($grants[$module];
    }
  }
}

As far as the others that doesn't seem like this provides a mechism for them. I thought it had, but trying to do an example has become hard. I know what the SQL should look like though. It needs to bind directly to the {activity_messages}.uid and say "none of these". So whats needed is {activity_messages}.uid NOT IN (2,3,54,6) where those are the private uids.

This looks good, so I'm thinking of a simple use case for this to illustrate and put into /modules/node.activity.inc before we actually put it in.

Desired result:
A setting at /user/%/activity/settings which gives a listing of accessible content types. Each content type to which the user has access has a dropdown of available options as listed in the original request.
label - Who can see your activity of this type?: Everyone, Nobody, Friends (Friends would be altered in by the friend module)

Maybe displayed as a table:
________________________________________________
| Content types: (derived from perms) | Permission levels: |
-------------------------------------------------------------------
| Photo | Dropdown |
-------------------------------------------------------------------
| Story | Dropdown |
-------------------------------------------------------------------

Looks promising but what is the storage for this kind of permissions?

#5 about UI /user/%/activity/privacy (suppose settings is different)

Basically we've sorta scrapped that UI i have illustrated above, instead we're leaning towards giving the user a list of any of the triggers that implement activity and allowing them to opt out of them. We pretty much have that working (not yet committed) and then we can hopefully work on more fine-grained permissions in order to allow say, a group to view certain activity, but not all of your friends. here's a screenshot to illustrate where it's going.

I'm contemplating the need to extend this. Currently it's either all or nothing - but I'm wondering if we can use the hook_activity_access_grants in order to provide a list controls. So for each of these item listed in the above screenshot, you have a dropdown that lists [flag_friend] [community] / [og] though the english would have to be something like, Do not show this to: groups (then list groups?) OR Do not show this to: my friends (and list particular friends?)

I dunno - maybe to complicated for now.

I'm going to make this as fixed and update the title for now. But if it comes up in the future, let's keep this issue in mind.