OG - Tweaking the UI for very large numbers of groups

That was fast. You're in Oregon right now for OS conference, yes?

I'll take a look at your code and see what I can do with it. Is it 4.6 compatible, or am I going to need to back-port it?

Thanks,
Rob

Well, hope you're doing well whereever you are, then.

I'm playing with the code, but frankly don't understand the UI in the admin=>group hierarchy screen. How is that UI used to establish a hierarchy? I see all of the groups that I've created since I activated the module, but it isn't obvious what to use that long empty space for. Listing sub-groups by name? Listing parent groups by name? Something else?

If it doesn't work yet, it doesn't work yet. I can still give it a hack :-)

How should it work, now that I understand that bit of info? BTW: I'd actually recommend the reverse UI in the case above, since you might have groups with very large number of sub-groups. But let me try it out now that I better understand what you meant.

Looks like the fields actually does assign a super group; I've looked at the records created in og_hierarchy, and that is consistent with that.

A few more questions about how you believe the code should behave once it works:

• What is the signficance of giving a group a role? Does that mean that once a user joins a group, that the user acquires the accesses of the group's role?
• What does "autosubscribe" mean, and what should it be used for?
• I've noticed that getting assigned to a parent group doesn't mean you can see the parent's content, which is the effect I'm trying for. But making og.module og_hierarchy aware is pretty easy. I'll do that and supply you a patch for that and a couple of other minor issues I've found in the code. That work for you?

I'll probably also factor things a bit, since I'll be calling your code mostly in background anyway, through my own UI.

Thanks,
Rob

OK, I have your code working, after making a very small modification in og.module that makes it "hierarchy aware": when creating the SQL for getting its "home nodes", og.module now checks to see if the function "og_hierarchy_get_parents" exists, and calls it to get parents groups.

[on second though, perhaps I should call "og_hierarchy_get_parents_all" instead???]

og.module generates slightly different SQL in this case; instead of

"na.gid = %d"

it generates something like:

"na.gid IN (" . implode(", ", $groups) . ")";

This seems to work, and if I understand Moshe's SQL, it will make sure that the right access checks happen for all of the parent groups as well.

This code definitely needs review, so anybody reading this who wants to use it now, YMMV ;-)

Here's the og_hierarchy patch as well.

Updated patch for og_hierarchy.module. I've added some API functions to allow other modules to manipulate the hierarchy tables:

function og_hierarchy_is_direct_parent($nid, $gid){
  $sql = "SELECT parent FROM {og_hierarchy} WHERE nid = %d AND parent = %d";
  $result = db_query($sql, $nid, $gid);
  if(!$result)
    return false;
  return db_num_rows($result) > 0;
}

function og_hierarchy_adopt_parent($nid, $gid){
  //For now,  just deal with og_hierarchy table
  if(og_hierarchy_is_direct_parent($nid, $gid))
    return; //once is enough!
  $sql = "INSERT INTO {og_hierarchy} (nid, parent) VALUES(%d, %d)";
  db_query($sql, $nid, $gid);
}


function og_hierarchy_divorce_parent($nid, $gid){
  //Delete any records one and all
  $sql = "DELETE FROM {og_hierarchy} WHERE  nid = %d AND parent = %d";
  db_query($sql, $nid, $gid);
}

New and improved patch. This one is now working in my site, and is getting some exercise from another module.

The change in og itself is very simple. All it needs to do is change its notion of a "home node". Currently, you put that logic into og_get_home_nodes_sql(). The function is only called twice, and it's immediately used the generate a db result containing the list of qualifying nodes.

My proposed change:

• Combines og_get_home_nodes_sql() and the actual query code into a new routine og_get_home_nodes($gid), which returns in the default case the same db resource you'd get from db_query on the old sql query.
• og_get_home_nodes checks for the og_hierarchy module. If it finds it, it constructs a "IN" clause, as so:
  

  function og_get_home_nodes($gid){
    //Make our code hierarchy aware
    $parents = array();
    $group_list = "na.gid = %d"; //chunk of extra SQL if needed
    if(function_exists('og_hierarchy_get_parents')){
      $parents = og_hierarchy_get_parents($gid);
      if($parents){
        $groups = array_keys($parents);
        $groups[] = '%d'; //add our own group
        $group_list = "na.gid IN (" . implode(", ", $groups) . ")";
      }
      
    }
  
    $sql = "SELECT DISTINCT(n.nid), n.status " . 
      "FROM {node} n INNER JOIN {node_access} na ON n.nid = na.nid " . 
      "WHERE $group_list AND na.realm = 'og_group' AND n.status=1 " .
      "AND n.type NOT IN ('og', 'image') " .
      "ORDER BY n.sticky DESC, n.created DESC";
  
    return db_query($sql, $gid);
  }
  

  This is almost the same as your old query, and if I understood your SQL correctly, does the same access checks as the old code did.

I'm not sure how best to generalize the notion of hierarchy, besides having some call get passed the "groups of groups" to which the group in question belongs.

Certainly, there are better notions of relating groups than hierarchy (my own application could nicely use a "taxonomy of groups", for example), but this solution required almost no change in your code, but works very nicely for a simple hierarchy.

Seth,

Here's how I'm using this modification, which may make it more clear to you.

Under the default model of og, to post content to a particular group, you must *belong* to the group. Also, you must mark the posting as targeted to that group.

When you need to publish to some large subset of groups, this is not tenable. So the hierarchical patch allows for the following publishing model:

1. Create a super-group for the set of groups you need to publish to regularly
2. People who need to publish belong to the supergroup
3. An item "published" to the group of groups is targeted to the super group

When you have hundreds of private groups where you need to hide even the existence one group for another, I have yet to see another solution that is as simple or as less likely to expose sensitive data to the wrong group of people.

As to Moshe's comment: as you and others have pointed out, the taxonomy access schemes do not play nice with og. Private groups mean private data, and you want an access scheme robust enough that it will actually keep private data private.

So in suggesting to me that I use a compound scheme using both og and taxonomy, I have to ask you: Hishtagaatah? Doesn't sound like too good an idea to me ;-)

Until a better documented, more robust means of combining access schemes is supported, hierarchy of groups strikes me as a lot easier to code and debug, and probably also to administer. With a hierarchical group scheme, you're dealing with only one access scheme. Do you have a better solution that actually works? If so, please describe it. But if you don't, please considering accepting this patch.

This is a group project, and the group has no obligation to accept any particular patch. But this code has been sitting out here waiting for review for a full month now. Is it too much to ask that someone give this code at least a bit of thought? I did. It's only courteous to look it over, especially after this much time.

Seth,

One addtional point:

While this adds a 'sense' of hierarchy, it's fairly invisible (and fairly useless right now as a result).
Subgroups don't show as nodes in their parents.

Yes. But not useless: I'm trying to prevent subgroups from showing as nodes for their parents. If the code did what you'd like it to do, I would not have written it.

Here's what the code is intended to do.

Suppose you have a family of groups {a, b, c, ...., z} that all belong to a super group S.

The object here is to have some group of admins that belong to S. Non-priviledged users belong to some group in the set of {a,...,z}, take "a" for an example.

A member of "a" should be able to contribute content to the "a" group, but to no other group.

A member of S should be able to contribute content that will be visible to any of the sub-groups.

This turns out to be a very good scheme to target content to some universe of users that are not all users.

It's not a suitable solution to allow users of individual groups to publish up into a super-group of users. But then again, that wasn't the idea.

Joe --

I've come to the general conclusion that the solution is to use og for this purpose very sparingly, or not at all. It's really the wrong tool for the job.

Part of the reason for this has been the way that CiviCRM uses Drupal roles to map to CiviCRM groups, which are very different from Drupal organic groups. CiviCRM can handle hundreds of groups. But Drupal really can't handle hundreds of roles, nor can OG handle hundreds of groups particularly well. OG also is very difficult to tie to an external resource like records in an LDAP or CRM contact store. Neither system is designed for these purposes, nor do I believe that either system will move in a direction that would permit it. I've given up the fight to push them in this direction.

Keep an eye on my work with the Green Party Of Canada. I believe it will prove a better solution to this problem than our previous efforts at making og CRM aware.