OG + project.module integration

hrm, looks like project is trying to do the right thing. check out project_comment_save() in modules/project/comment.inc, around line 168. we definitely do a node_load() there, before we do the node_save(). i sprinked in a few calls to dprint_r() and saw that the $node that we hand off to node_save() definitely still has the og_groups and og_groups_names fields set correctly as i'm saving a follow-up. furthermore, i stuck some dprint_r() calls directly into node_save(), and saw og_groups and friends were still there during (and after), the node_save(), too. any other ideas?

thanks,
-derek

well, the real problem is that since issue follow-ups aren't nodes and they aren't comments, that neither og_nodeapi() nor og_form_alter() realize they have any work to do in this case. :( so, the issue followup form is just not including anything about the audience, and when we save the node from the form, we wipe out the audience completely.

seems like the only possible solutions are:

1. test for "module_exists('project')" inside og_form_alter() and have a special case for the 'project_comment_form'
2. test for "module_exists('og') inside the project code and do something sneaky and og-specific
3. add an "og_project" contrib module that implements og_project_form_alter() to handle this case (and any other possible form_alter stuff we'll need as i continue to find problems with the interaction between og and project).

#3 seems like the best choice all the way around, but that involves introducing yet another og contrib. the good news, of course, is that neither og nor project need to have their code polluted with compatibility checks and calls. i'd be willing to write and maintain such a thing, but in irc, webchick said i should get the blessings of moshe before i plow ahead to implement and commit it.

comments/thoughts?

thanks,
-derek

it'd be nice if the og.module's code to insert all the audience stuff was moved into a separate method so that it could all be shared by both og.module and og_project.module. moshe, would you accept and apply a patch that accomplished that?

thanks,
-derek

(not sure if i should just open a new issue about this form_alter() refactoring...)

here's a patch for basically all i had in mind. let me know what you think. sadly, i haven't quite been able to solve my initial problem with issue followups removing the group audience. i'll post my current draft copy of og_project.module with some more info in another reply...

here's my draft copy of og_project.module.

it (mostly) works to add the OG fields to the form when following-up to an issue (although, it adds them *after* the preview and submit buttons, which is a little weird). sadly, the end result is still broken. even once the form has the appropriate group audience boxes checked off, the issue still doesn't get saved belonging to any groups at all. :(

i'm not exactly sure what's going wrong here. any insights would be appreciated. the #node vs. nid hackery in the project_comment_form is an attempt to reuse the existing og_form_alter() code as much as possible (or, in this case, og_form_add_og_audience() from the patch in comment #8 here). depending on which project module patches you've applied or what version you're using (see below), the nid might be in a different spot in the form tree. it's a little ugly, but it seemed safest to write the code to be able to handle different possiblities (at least for now).

if you want to attempt to test this on a local site, you'll need to apply (at least) the following 2 patches to the project module (fixes to known bugs that are just pending review before they can be committed):

• project_no_empty_followups.patch from #60125
• project_issue_followup_no_version_1.patch from #61983

let me know if i can provide any other useful info. i added a dprint_r($node) inside og_save_permissions(), and at that point, it had real values for the og_* fields:

    [og_public] => 1
    [og_groups] => Array
        (
            [0] => 1
        )

    [og_groups_names] => Array
        (
            [0] => Condor
        )

comparing that to the output when the issue first gets created seems the same. in that case, the issue shows up belonging to the group. it's only after you follow-up does the group get lost, even with this og_project.module enabled.

any wisdom would be most appreciated!
thanks,
-derek

ok, i committed the patch from #8 into both HEAD and DRUPAL-4-7. seeing as how this is all about form_alter(), and that's new in 4.7, i don't see how angie could backport this to 4.6.

i'm setting this issue back to active, since now i must turn my attention to getting that og_project.module working. there's still something not-quite-right about issue followups, and even though the group audience settings are now showing up on the form, they're not getting saved in the node. any insight/help with that would be greatly appreciated.

thanks,
-derek

simplified version of og_project.module for testing. still not quite right, but i'm getting close to understanding why the groups are getting cleared when you followup to an issue...

now that http://drupal.org/node/67753 has been fixed, i finally got og + project working together. i just committed a simple og_project.module to cvs and created http://drupal.org/project/og_project. any futher discussion on this topic should move into http://drupal.org/project/issues/og_project, or as new issues against OG for specific problems.

thanks,
-derek