Propagation of Posts Up or Down an Ancestry Tree

I think saving the grandparents of a node makes the most sense. In thinking about how to do this, I came up with two new functions and thought it better to discuss before submitting a patch.
og_subgroups_save_grandparents() runs when a node is updated and is similar to og_save_ancestry(). og_subgroups_save_grandparents() gets an array of the parent and grandparent groups for a node. Note that this depends in part on my proposed patch http://drupal.org/node/143530#comment-246297 that helps to provide a $node->og_groups array for subgroup nodes.

The challenge with the og_subgroups_save_grandparents() function is that it does not delete previous grandparent records from the og_ancestry table. It has no way of determining which record(pair of nid and group_nid) refer to a grandparent relationship. Perhaps it would make the most sense to save parent and grandparent information in a single function. This would require og_subgroups to override the og_save_ancestry function. Perhaps a bold step ;-)? This is up to the maintainer of og_subgroups.

function og_subgroups_save_grandparents($this_node) {
  $tree = og_subgroups_get_ancestry($this_node);
  drupal_set_message(dprint_r($tree, TRUE));
  //drupal_set_message(dprint_r($tree, TRUE));
  foreach ($tree as $this_tree) {
    foreach ($this_tree['parents'] as $parent){
      $this_parent = node_load($parent['nid']);
      if (!og_is_omitted_type($this_parent->type)) {
        //$sql = "DELETE FROM {og_ancestry} WHERE nid = %d";
        //db_query($sql, $this_parent->nid);
        $gid = $parent['nid'];
        $sql = "INSERT INTO {og_ancestry} (nid, group_nid, is_public) VALUES (%d, %d, %d)";
        drupal_set_message("sql:" .$this_node->nid . " " . $gid);
        db_query($sql, $this_node->nid, $gid, $this_node->is_public);
      }
    }
  }
}
function og_subgroups_get_ancestry($node){
  $tree = array();
  foreach($node->og_groups as $key => $value) { 
    $tree[$value]['nid'] = $value;
    $tree[$value]['title'] = $node->og_groups_names[$key];
    $tree[$value]['parents'] = og_subgroups_get_parents($value);
  }
  return $tree;
}

I've cleaned those two up a bit -- og_subgroups_get_ancestry will no longer return redundant values.

function og_subgroups_save_grandparents($this_node) {
  $tree = og_subgroups_get_ancestry($this_node);

  foreach ($tree as $this_tree) {
    foreach ($this_tree['parents'] as $parent){
      $this_parent = node_load($parent['nid']);
      if (!og_is_omitted_type($this_parent->type)) {
        //$sql = "DELETE FROM {og_ancestry} WHERE nid = %d";
        //db_query($sql, $this_parent->nid);
        $gid = $parent['nid'];
        $sql = "INSERT INTO {og_ancestry} (nid, group_nid, is_public) VALUES (%d, %d, %d)";
        drupal_set_message("sql:" .$this_node->nid . " " . $gid);
        db_query($sql, $this_node->nid, $gid, $this_node->is_public);
      }
    }
  }
}
function og_subgroups_get_ancestry($node){
  $tree = array();
  foreach($node->og_groups as $key => $value) { 
    $tree[$value]['nid'] = $value;
    $tree[$value]['title'] = $node->og_groups_names[$key];
    $tree[$value]['parents'] = og_subgroups_get_parents($value);
    foreach ($tree[$value]['parents'] as $parents) {
      unset($tree[$parents['nid']]);
    }
  }
  return $tree;
}

Also, here's some example output from og_subgroups_get_ancestry() :

Array
(
    [44] => Array
        (
            [nid] => 44
            [title] => Example Event
            [parents] => Array
                (
                    [43] => Array
                        (
                            [title] => Drupal Stadium
                            [type] => venue
                            [status] => 1
                            [nid] => 43
                            [is_active] => 1
                        )

                    [41] => Array
                        (
                            [title] => Leo Kottke
                            [type] => artist
                            [status] => 1
                            [nid] => 41
                            [is_active] => 1
                        )

                )

        )

)

At http://drupal.org/node/143530#comment-249724 swood writes:

I'm working on incorporating your changes into the current version. I hope to have something in the next few days for a release.

One question though: In your previous comment you stated: "In creating this patch I discovered that posts inside of a subgroup do not show on the homepage of the parent group and aren't included in parent group new content notifications. This is something I'd like to add. I'll create an issue for it."

Isn't this backwards? I would think that posts created in the parent would be visible within the children, but not the other way around. A subgroup is subset of a larger whole. I wouldn't think that posts within a subgroup would be visible by the entire group. If so, then there wouldn't be any privacy within a subgroup.

I believe that there are two rules that should work here:
1. Members of a subgroup are automatically members of the parent.
2. Posts within the parent are visible within the subgroup(s)

I think the propagation of posts from subgroups to groups or vice versa should be a configurable option because either might be totally appropriate (or inappropriate) for a given site.

In my case, Events can be sub-groups of of Speaker and Venue. I would like a post that discusses a particular event to show up in the Group for both the speaker and the venue.

Does this help clarify?

The point of my post was that it could make sense for propogation to go up or down the ancestry tree depending on the use of the website. That is why it should be a user-configurable option. Using a view of parents + subgroup on a subgroup page would not achieve the same functionality as it would not provide the subscription to content -- an essential feature of OG.

I don't follow how OG_Taxonomy would make sense for this application.

This patch adds a configuration option to select whether posts created in side of a group\subgroup propagate up or down the ancestry tree.

Let's say I have 2 Groups: A and B, that are parents of subgroup C. When propagating up the tree, a post inside group C would also be a post inside of A and B. When propagating down, a post inside of A would become a post inside of B.

Note that this now includes an .install file. Current users of OG_Subgroups should run update.php after applying this patch.

Rename this to .install. Is there any better way to add a .install file to an issue?

Forgot to mention: If you review the contents of the patch, you'll see that I've re-written the example functions. Still, we're able to handle propagating in either direction using the same 2 functions.

...modified the patch to spell 'propagation' correctly ;-).

I'll need to re-roll this patch as I've found a bug. og_subgroups_get_family() function should verify that a node has parents before looping over the parents, otherwise creating a node that is not a member of a group will result in an invalid foreach error.

I hope to re-roll this evening.

The modified function will look like this:

function og_subgroups_get_family($node, $relationship_type) {
  $func = og_subgroups_get_ . $relationship_type;
  $tree = array();
  if (is_array($node->parents)) {
    $parents = $node->parents;
  }
  else {
    $parents = $node->og_groups;
  }
  if ($parents) {
    foreach ($parents as $key => $value) {
      $tree[$value]['nid'] = $value;
      $tree[$value]['title'] = $node->og_groups_names[$key];
      $tree[$value][$relationship_type] = $func($value);
      foreach ($tree[$value][$relationship_type] as $this_member) {
        unset($tree[$this_member['nid']]);
      }
    }
  }
  return $tree;
}

I've re-rolled the patch against head. This should work now! Don't forget the install file!

Ack. This patch applied successfully but put code from the settings form into the wrong function. CVS never mistakes, so it must be human error.

I'll re-roll again.

This works for me. Your feedback is appreciated!

This patch has a slight flaw that does not preserve the public\private status of groups. I will post a correction.

My apologies for the unfortunate delay re-posting this. Could someone please review?

Please make sure that you're applying this against CVS revision 1.12. Is that the case?

Committed. Catch the changes when the dev version is repackaged. If anyone wants to contribute a patch to prevent circular\impossible\nonsensical parent\child relationships, I'd be happy to take a look at it.

This patch is now part of the latest release, 5.x.3.0-dev, released today.