Make og_project work with projects that are standard group posts

The use case is pretty simple; I have groups, each of which can have subgroups (using og_subgroups) and projects. In a corporate environment, it is common to have the requirement that all members of a team (group) have access to all of the team's projects. og + projects as standard group posts fits this requirement well. To be more explicit, without this patch, og_project requires that the og settings for the project_project content type be "group node", whereas this patch also allows projects to be "standard group posts" and "wiki group posts".

My system is configured so that normal users cannot change the group that a project is in. It shouldn't be too much work to clean up the group membership of all of the project issues whenever the group membership of a project changes, though. I will add that functionality and submit a new patch.

I don't really feel that comment-driven fits in to my use case. Only certain users can change the group a project is in, and such changes are rare. Putting controls to do this in the comment is not the way I'd like to see it work for my use case, so I still see og_project as a useful, separate entity.

Finally, as the person with the more complicated use case, I don't agree that this should be done in a separate project. I can understand that those who only need the simpler use case might not want to support standard group posts, but if I were to take this feature to another project, it wouldn't really take any significant additional effort to support the standard-group post 1-1 use case. I'd be happy to help maintain these features, if this patch ever advances to the point where it is acceptable enough to be committed here.

Thanks. I will post an updated patch as soon as it is ready.

Just an FYI, the patch in #0 does not work correctly when you edit a project issue; the issue is reset to a public post with no group info. I've fixed the bug, and will post an updated patch when I'm finished with #2.

Okay, here's a patch. Tested lightly with both projects as group nodes, and projects as group posts.

When projects are group nodes, changing the project that an issue is associated with will change the issue's audience to be the project (group) node. The 1-1 mapping is enforced; og_project already hides the audience control for project issues.

When projects are standard group posts, changing the project than an issue is associated with will change the issue's audience to match the audience of the issue's new project. There is still an imposed relationship in effect here: the audience group(s) of every issue is always the same as the audience group(s) of the project they belong to. If a project belongs to multiple groups, then each of its issues will belong to the same set of groups. The audience control for issues is still hidden, though; it is not possible to change the audience of an issue independently of its project.

Finally, when projects are standard group posts, the audience of all of the project's issues will be adjusted any time the audience of the project itself is changed. I figured that it would be too slow to call node_load on all project issues, so I manipulate the database directly with SQL statements to affect the updates.

As I write this, I realize that I did not handle project_release nodes, but I don't have time to do that right now. The code should be more or less the same as the project_issue case, though.

Hm, I might be able to use a variant of the sql at http://drupal.org/node/173639#comment-4102270 to make the update in #6 more efficient.

I realized that the SQL optimization mentioned in #7 is probably possible, but only if every project has exactly one group. Perhaps it would be sufficient to check the og group limit setting for project_project on the og_project settings page, and report any discrepancies there. Perhaps we do not let the user turn on the feature to track project audience unless this limit has been set.

Unassigning; don't need this any more.