Create subgroup link not available

See documentation page on Settings: http://drupal.org/node/163567

Changing this to "support request" unless you have followed these settings instructions, and the users with the correct permissions still do not see the link.

Is this resolved?

no, I have the same problem. I have tried following the instructions several times and still no luck.

The version of og_subgroups that I use which is working and provides the correct link is: 5.x-4.x-dev

Below is the code which creates the "Create subgroup" link in the first place. It has nothing at all to do with the og_subgrouups.module other than the fact that it's required to be installed before the link will appear.

/**
 * Implementation of hook_node_info().
 */
function og_user_roles_node_info() {
  // If og_subgroups is installed AND og_user_roles_create_subgroup checkbox is checked;
  if (module_exists('og_subgroups') && variable_get('og_user_roles_create_subgroup', 0) == 1) {

    return array(
      'og_user_roles_subgroup' => array(
        'name'        => t('Subgroup'),
        'module'      => 'og_user_roles',
        'description' => t('Create a basic subgroup.'),
        'help'        => t('Create a basic subgroup.'),
        'body_label'  => t('Description'),
      ),
    );
  } // end if
}

The user MUST have the create og_subgroups permission in order for this link to appear. And, your OG User Roles must be working in order for this link to appear on a group menu.

To test whether your OGUR roles are working, give the user the create og_subgroups permission site wide (not group limited). If the link appears, then OGUR roles aren't working. If the link still does NOT appear, then our problem is elsewhere.

I would try weighting OGUR higher than your other modules. And in particular, higher than the core modules.

Another wild guess is that you might want to change this line:

  if (module_exists('og_subgroups') && variable_get('og_user_roles_create_subgroup', 0) == 1) {

to this (just add another "="):

  if (module_exists('og_subgroups') && variable_get('og_user_roles_create_subgroup', 0) === 1) {

Doing something similar to this actually fixed another weird problem.

Hi,

I had this problem recently and solved it in my situation.

I am also using Content Type Administration for OG which allows some groups access to certain content types and others not. This module "takes over" the group details panel that is normally displayed by OG and substitutes its own (with only the allowed content types visible).

With that background, I discovered that the content type "subgroup" was not enabled in my installation in the "Content type for OG" administration panel.

I enabled it (necessary) but alone this did not solve the problem.

In the Organic Groups administration panel, in the content type section, the content types are editable. In each, the administrator must choose (at the bottom of the edit screen) how Organic Groups is to treat this content type.

Options:

Group node
May not be posted into a group.
Standard group post (typically only author may edit). Sends email notifications.
Standard group post (typically only author may edit). No email notification.
Wiki group post (any group member may edit). Sends email notifications.
Wiki group post (any group member may edit). No email notification.

When the subgroup content type is created, it is defaulted as a 'Group node'. This makes sense.

However, the problem comes when OG Content Types considers it. If it is a group, it seems (I haven't looked at the code) that OG Content Types does not think that it is "content" that gets posted into a group ... and excludes it from the Create Content links on the group details block.

To confirm this idea, I changed the default setting for the Subgroup' content type to:
"Standard group post (typically only author may edit). Sends email notifications."

Voilla !!! The "Create Subgroup" link appeared and functioned as expected (given that all the access permissions were correctly specified).

A subgroup was in fact created, it was in the right place in the respective hierarchy, OG_Subgroups displayed it and its members correctly in the "tree" tab and its hierarchal relationships were correctly editable in the "subgroups" tab displayed when the group "edit" function is active. OG User Roles recognizes and respects its existance allowing me to specify and assign group roles and OG_Content_Types allows me to restrict content.

So far, all of the behaviors that I am aware of seem to function correctly in the subgroups created in this way.

*******Concern**********

Having said all that, I have a nagging concern that ... specifying 'subgroup' content type as standard group post will cause OG to miss some critical control that it does if it knows that a content type is a group.

Does anyone ... Moshe or his team, maybe? ... Know what future havoc I may have created? How will OG treat this content type differently if it is not specified as a group? If OG does not recognize it as a group, why are things seeming to work so well now? (note ... barely audible erie noises and suspense music gradually rising in background and very occasional random electric discharge visible in the air around the monitor late at nite when its dark ...)

The only two hints I found (in README.txt Organic Groups 5.x-7.2 install package)

- On admin/og/og, see the content types table at the top. Click edit beside each type to set its 'usage'. You usually want to create a new node type via admin/content/types page and then designate that node type as a group from here. See the first item in NOTES below. 

- This module supports designating any type of node to be a group. This node type should be defined by a custom module or via the admin/content/types page. When defining your type, you usually want the title label to be 'Group name' and the body label to be 'Welcome message'. Since all nodes of this type are treated as groups, you will usually not want to designate the standard page, story, or book node types as groups. The capacity to make custom node types groups means that you can have custom fields for your groups and even several different kinds of groups. 

The language of these notes was suggestive (in my reading) rather than restrictive. They do not say "all content types intended to be group nodes *MUST* be designated as "group" on the Organic Groups Usage selections for OG to function correctly." (extreme clarity is a fantasy of mine ...)

Ideas, answers, musings, similar concerns? Anyone?

Thanks

Thanks jackspiv! That was a tough one!

Having said all that, I have a nagging concern that ... specifying 'subgroup' content type as standard group post will cause OG to miss some critical control that it does if it knows that a content type is a group.

With respect to your concern, the content type that the new subgroup is saved as is actually determined by the OGUR setting:

Group type to use for subgroup creation:

In my case, I always set this to my primary group type -- for me, typically 'group'. The 'subgroup' content type is used ONLY to create the link on the group menu to "Create subgroup". The 'subgroup' is actually created as a 'group' content type.

Hope that makes sense.

SomebodySysop,

Thanks for responding.

I noticed that "subgroup" is actually created as a "group" content type by default.

In the edit group setting (added by the OG module) I changed "group" to "Standard group post (typically only author may edit). Sends email notifications."

My concern is that as I set it, this content type (subgroup) is no longer the appropriate "group" type that your module originally set. My further concern was what the implications of this might be for the OG module. For example, I had expected that it might no longer show up in groups lists ... (if OG didn't "treat" it a group) but it does. I don't know what will be broken or not. Perhaps the original content type it was created as stays in the database and OG adds an additional variable to describe how it "treats" the group content type (in this case the "subgroup")

Its a concern/question that might be appropriate for both this group and OG. But my questions in OG have gone unanswered for about 6 months now. Either I've been banned without notification or everyone's busy on the V6 port or something ...

Again, "Subgroup" as a content type ONLY exists to create a "Create Subgroup" link on your group home page. You define the content type that is actually saved in OGUR Settings. Since you can define any group type you want, that should allay your concerns.

My concern is that as I set it, this content type (subgroup) is no longer the appropriate "group" type that your module originally set.

Again, again: Your subgroup content IS NOT created as a "Subgroup" content type. It is created as the content type you define in OGUR Settings, Group type to use for subgroup creation:.

My further concern was what the implications of this might be for the OG module.

As long as the content type you define in OGUR Settings, Group type to use for subgroup creation: is also defined as an OG Group Node in OG Settings, you won't have any problems. It will only appear in the OGUR settings group list if it is an OG group node.

Its a concern/question that might be appropriate for both this group and OG. But my questions in OG have gone unanswered for about 6 months now. Either I've been banned without notification or everyone's busy on the V6 port or something ...

I would imagine OG gets a lot more support requests than OGUR. However, I think they should refrain from bad-mouthing other people's modules if they aren't going to take the time to help when people need it.

SomebodySysop,

Thanks for taking the time to clarify this (sorry I didn't respond sooner). I think I finally get it.

Just to test my new understanding ...

If the only reason for the creation of the Subgroup content type is to get it to post to the group details block ... would it make sense to have it default on installation (in OG settings for content type) to either

"Standard group post (typically only author may edit). Sends email notifications."
or
"Standard group post (typically only author may edit). No email notification."

This would not solve the issue around enabling the content type in OG_Content_Type_Admin in #7 above but would solve one of the two challenges I experienced.

Any downside?

I guess that does make sense. However, it won't appear on the group menu unless it's checked on OGUR settings. I'll have to think it through a little. Thanks.

Thanks for considering it.

It also won't appear ... if you are using OG_Content_Type_Admin like I am ... unless it is enabled under those (OG_CTA) settings also.

In my case, there were three settings that I had to find and fix. Only one was obvious from the OGUR Readme instructions.

It was especially counterintuitive that the visibility of a (create subgroup) link presented by the OGUR module would be controlled by another module ... although, of course, it makes sense...

Reducing this by even one would be a considerable reduction in braindamage for the casual user.

A summary for those who have followed this far. (much of this is in the readme files for various modules)

To make the "create subgroup" link visible (my experience)

1) go to og settings menu and find subgroups in "content types". set it to 'standard group post"
2) go to og_content_type_admin (if you are using it) config and enable the subgroup type in sitewide and default tabs
3) go to og_user_roles admin page and find create subgroups section and enable "Create link to "Create Subgroup" in group menu?"
4) go to access control admin page and verify that you (and all roles that you want to give access) has permission for "create og_subgroups" and "create group content"

Thanks for all your help, SomebodySysop

If it's any consolation, I've added these notes to online documentation on subject here: http://drupal.org/node/334886

On the contrary,

I'm honored :)

If anyone manages to avoid the hassle above it was well worth it.

(and much less trouble than writing an awesome module like this !!!!)