Let any node type become a group

i'm skeptical that this can work easily for the typical admin. but i'd look at a patch if someone submitted it.

the user experience for an admin should not be diminished by this patch. "'Please come back to this page after selecting a node type." is not sufficient. I'm a bit skeptical that this is worthwhile. What additional fields are desired in a group? Can you not add and display those fields using nodeapi('form post') and nodeapi('view')

Just a suggestion for selecting a node..I'm doing this type of thing in another module.

The challenge of finding some random node for your module can be daunting, as there are so many ways to sort/search/filter nodes. You can just set a flag that says "looking for node to do X". As long as the current user has this flag set, you can use nodeapi to place links with every node that they view that would allow them to select that node for whatever purpose. You might also want a "cancel searching" link as well.

This would even allow a user to create a new node and select it. The selection link can redirect back to the starting page, too.

I need this. marking as active

actually i don't think this is going to work. i need to override the hook_view() for whatever node type becomes a group. thats no possible in current drupal.

for my project, i am going to try and extend the og node type using nodeapi('form post') and friends.

Sounds good killes. I will consider your patch. I think og will have to completely replace the hook_view output for the chosen node type via nodeapi('view'). in its place, og_nodeapi('view') will show the group home page.

Ok, I think I am getting somewhere.

Attached is a patch which should work. It also reverts one of the recent commits, as it broke the settings page.

A module that would want to create a node type that can be an OG would need to duplicate the actions of the og_insert, og_update, og_form, og_view, and og_load functions or call the functions from its own similar functions.

A patch that will let use casetracker.module to use this patch has been posted here: http://drupal.org/node/56218

most people will want to use CCK nodes for this. Surely we won't require programming in order to use og. Thats what I understand from the comment "modules must implement the functions ...". Shouldn't og itself save those in nodeapi(insert/update). Thats how event, location work.

point taken

Ah, and the patch is even somewhat tested. it would help if somebody with an existing OG installation could test it on a copy of his datatabase by setting "og nody type" to say blog and changing all og nodes to blog.

I'm not crazy about all that conditional code. Perhaps we should model event.module and ship with a basicog.module

as i read over the code. i'm wondering if we should should let admin designate multiple node types as 'og' types. that way, sites can have different kinds of groups. we would have to let variable_get('og_node_type', 'og') return an array and change a little bit of code to enable this. i would draw the line there though. i don't want og to behave differently for different node types. Anyone think this is valuable?

there is a stray print_r in the nodeapi(validate)

the code looks good. i will give it some testing

+1

I think the patch should be fine, my biggest concern were "strange" access issues because with this patch a group nodes access will not anymore be controlled only by its own access and perm funtions. However I can not think of a scenario where this would result in an unintended behavior.
However I had no chance yet to really test the patch. I will definately run the automated tests on the patch once there are some more.

FYI, I intend to commit this patch to HEAD and 4.7 after I have tested it further and gathered more feedback. Neither killes nor I plan to backport this to 4.6. Fortunately, webchick has agreed to maintain the 4.6 branch of og for some time so she will be deciding what gets backported. Thanks to webchick for undertaking that effort.

@killes - 8 hunks failed. if you can update this, we'll review and commit before anything else gets in. also consider doing an update function. i figure that function should:
- enable og_basic.module (or make sure it is already enabled - else die())
- UPDATE n.type = og_basic WHERE n.type='og'
- make sure that og_basic type is recognized as an og type

ok, this is nearly ready to go. depends on http://drupal.org/node/58330. feel free to test this, folks.

committed to HEAD and 4.7. thanks.

For the record, I don't have any plans of back-porting this to the 4.6 version. It's too big of a change for this late in the module's lifecycle, imo.

Can anyone help me understand what this functionality is good for?

I'm currently implementing a series of Voice Over IP (VOIP) modules for Drupal and one of them will allow users to create voicemail groups, send voicemail and audioblog messages to members of the group, etc. I wonder if my group voicemail module would benefit from becoming an OG-enabled module, or if it would be better for me just to call the og_basic module whenever needed.

Also, I'm currently implementing everything for 4.6 -- so that it would be compatible with CivicSpace installations -- but depending on what you guys decide to do I may have to switch over to 4.7 sooner than I expected. Please let me know what you think, ok?

BTW, how the integration with CiviCRM? Does that run smoothly on 4.7 as well?

thank you so much for the great and inspiring work you are developing,

Leo