Add option to choose which group types can be used to create hierarchies

Massud, thanks for taking the initiative with this, its a great start. I've reviewed that patch and the functionality that it provides. Below is what I found that needs to be changed/improved before the patch can be accepted.

1. Move the “Allowed subgroup types” checkboxes to the subgroup config settings page at admin/og/subgroups. This will remove some redundancy and centralizing the subgroup settings is a more intuitive approach.
2. When the module is uninstalled, delete the new og_subgroups_allowed_subgroups_* variables.
3. The subgroup parent selector needs to filter out the content types that are not allowed to be subgroups.
4. The entire subgroup parent selector fieldset should not show up on the node add/edit form for content types that are not allowed to be subgroups.
5. The Hierarchical Select Subgroups module needs to accommodate the “allowed subgroup types” settings by only returning the “allowable” groups.

Let me know if you have questions.

thanks for the updated patch. I'll install it and take a look. #1 above definitely clears up the misunderstanding on how you are setting it up. I hadn't envisioned it working that way, but I think its beneficial.

Once the core subgroups module is set up with this new feature I'll take care of the Hierarchical Select module.

I'll get back to you after I review the patch.

I'm getting an error when applying the patch and its not creating the og_subgroups.js file.

$ patch < og_subgroup.patch 
patching file og_subgroups.module
patching file og_subgroups.install
patching file og_subgroups.js
patch: **** unexpected end of file in patch

I'm not able to properly test.

-morbiD-

However, if your hierarchy is defined such that content type "generic_group" can have children of type "generic_group," that implicit restriction no longer applies, allowing an infinite number of levels:

generic_group > generic_group > generic_group > generic_group > generic_group > generic_group ...and so on.

I don't see this as a problem as some use cases would need to allow for an infinite number of levels to be created. Also having a restricted hierarchy such as organization > department > team would also need to be accommodated. Both of these use cases are exactly what I need to utilize in my projects at work.

I thought about some use cases and here are some examples we can use in developing this patch:

Use case 1: Organic flat groups
Suppose there is a group type called Interest Group. Interest groups would be similar to groups.drupal.org in that groups can be created for a particular subject or interest and hierarchies are not allowed to be created using interest groups.

1. In this case the Interest group type should not appear in the parent selector for other groups.
2. On the node add/edit form for interest groups the “Subgroup” field set should not even appear because this group is not subgroup-able.

Use case 2: Organic sub groups
Taking use case #1 a bit further, suppose a site needs to be able to create hierarchies out of the interest groups in order to create something like the following:

• Motorcycle Racing
  • Motocross
  • Supercross
  • Superbike
  • Supermoto
  • Enduro
  • …

In this case a simple or complex hierarchy should be possible and only the interest group type can be use to create the structure. This would allow for an infinite amount of branches to be created.

When adding or editing an interest group hierarchy, all interest groups will need to be selectable in the “Parent” field, represented in hierarchical form.

Use case 3: Pre-defined Hierarchy
In this case a pre-defined hierarchy means that a limited number of levels can be created. Here is a real life example using the Arizona K-12 School system. The structured levels will be Organization > County > District > School.

• AZ K – 12
  • Apache
    • Alpine Elementary District
    • Chinle Unified District
      • Chinle Elementary School
      • Chinle High School
      • Chinle Junior High School
      • …
    • Concho Elementary District
    • …
  • Cochise
  • Coconino
  • Gila
  • …

The Organization group type would be at the top level, County groups can only be children of Organizations, District groups can only be children of County groups and School groups can only be children of Districts.

The patch so far is shaping up to handle these use cases but I can see some areas that need to be adjusted. I'll list my findings once a new patch is posted that I can install.

@-morbiD-

yeah you're right about having an optional subgroup limit field to help keep things under control. If massud wants to add it into this patch then cool, other wise we can create a new feature request and get it added in that way.

I tested the patch and I have identified some issues with each of the use cases described in comment #9.

Testing Use case 1:

When testing this use case (no allowable subgroups have been selected) it functions properly in that I can only create groups at the root level. Here are a few things to improve this functionality.

1. Create a way to disable subgroups for a particular group type.
2. When a group type has subgroups disabled, the Subgroups fieldset should not show up on the add/edit forms.

Testing use case 2:

1. When creating a new interest group from Create content > Interest group (node/add/interest-group) the parent field in the subgroups section only has the top level interest groups. The parent selector needs to return all interest groups in hierarchical order. That way this new interest group can be added as a child to any portion of the tree.

2. Clicking the "Create Interest Group" link from the OG block doesn't work the way I would expect. When I click this link I see that the group's gid is passed in the URL which tells me that the new group will automatically be added as a child to the group represented in the gids[] param. But when submitting, the group is created at the root level. I see that the subgroups fieldset is collapsed and when I open it, is selected. When expanding the Parent field, the options only shows the interest groups at the top level, I can't even select the group thats represented in the URL.

Here's the way I think this link should work when clicked:

• A message is displayed at the top of the group creation form telling the user that this group will automatically be added as a child to group "blah" (which is the group represented in the URL).
• The subgroups fieldset should remain collapsed, but if opened, the parent value should be pre-selected and the user should not be able to change it.
• When submitting the form, the parent group should be the group that is represented by the url param.

Testing use case 3:
The patch is shaping up to handle this use case nicely but I may have encountered a bug when trying to build a structure like: Organization > County > District > School

When creating an organization group called Arizona K-12, it works as expected. When creating a county group called Maricopa it works as expected in that I was able to choose the Arizona K-12 group as the parent. But when trying to create a district group called Mesa Unified District, the parent selector is returning top level and Arizona K-12 only. It should return the county group called Maricopa. So currently I'm unable to build out my pre-defined hierarchy. The Allowed subgroup type variables are set correctly:

og_subgroups_allowed_subgroup_types_organization	a:1:{i:0;s:6:"county";}
og_subgroups_allowed_subgroup_types_county	a:1:{i:0;s:8:"district";}
og_subgroups_allowed_subgroup_types_district	a:1:{i:0;s:6:"school";}
og_subgroups_allowed_subgroup_types_school	a:0:{}

I'm not sure whats causing this issue.

The current version of the module allows for a hierarchy to be created by any group automatically. And any group type can be a parent or child of a different type. I don't want these new settings to change that behavior if the allowed subgroup types is left blank. I don't want this new version to disrupt current installations.

So with that being said I think a checkbox that disables subgroups for a group type is the way we should go. I do like your idea of changing "Allowed subgroup types" to "Allowed parent group types" because it will have a better work flow when defining hierarchies. With the "Allowed subgroup types" method, when I create the Organization group I can't select the County group to be the child because it hasn't been created yet. I then have to return to the Organization content type settings page after the County group has been set up to make County the allowed child. Changing the settings to "Allowed parent group types" would eliminate that workflow.

I need to look further into your comments for Use Case 3 and see what I can come up with for a solution. But as far as user experience goes, I don't want them to be able to select a group then have the form validation tell them that they cannot select it. If they shouldn't select it, it shouldn't be in the Parent selector field.

I have not looked into the "Privileged users to create subgroups" portion of the patch yet. I'm taking this one step at a time.

I found a bug in the patch that might help make forward progress. In the og_subgroups_tree_recurse() function you added a check in an IF statement that never passes.

Look at

if ($node->gid != $exclude && in_array($gid, $groups)) {

and change it to

if ($node->gid != $exclude && in_array($gid, array_keys($groups))) {

I'm not uploading a patch because its a simple change and I don't want to give you any headaches in applying a patch if you've already started modifying the existing one.

The patch is working better now, still a couple issues I'm finding.

To keep backward compatibility, all group types are allowed to be the parent by default. So, I think we don't need to add an additional option to disable subgroups.

yeah it works well the way you have it. I say we leave it as is and if someone wants it any different they can create a new issue for it.

Use case 1
done!

Use case 2
The functionality for this use case is working great, the only thing I would like to add is a simple UI component:
1. When clicking on "create interest group" from the OG block, a message should be displayed at the top of the form telling the user that the new group will automatically be a child of "blah".

Use case 3
I'm still getting the similar issue that I posted about before. When I try setting up a structure like Organization > County > District > School, the subgoup fieldset is not showing up on the add/edit form for District. Organization and County groups are working great though.

Was testing out the "Privileged users to create subgroups" portion and it doesn't seem to work. All three settings, Admins, Members, and Everyone doesn't make that link show up. Looks like the link only shows up for the Node author.

It appears that the issue is in the og_subgroups_og_create_links() function, look at:

if (module_invoke($types[$subgroup_type]->module, 'access', 'create', $subgroup_type, $user)) {

you are invoking the node_access function which will basically check the user account against all of the privileges found at admin/user/permissions for the node module. In this case it will always return false unless its the node author. You either need to forget about using that IF statement, or look at implementing hook_node_grants function.

The privileged users to create subgroups feature is working, but I guess I assumed it would or should work a bit differently. I was able to get it to work when I gave my test users the "create content" permission. I could then toggle the radio button between group members and group admins and that link would show and hide properly.

The "Everyone" option doesn't work due to the fact that the Group Details block is only available to group members, otherwise that block just has a "Join" link. To me, "Everyone" means any non member could create a subgroup. Is that what its supposed to do? Explain your intentions behind the Everyone setting.

It would be nice to have the privileged users to create subgroups settings not rely on the node create permissions. Look at my scenario...

I have a normal group member with no extra privileges and I have "group member" selected for the privileged users to create subgroups field. When that user visits the group page, the "Create Interest Group" link does not show up. I give that user the create interest_group content permission and now that link shows up. The problem with that is now this user has access to Drupal's default "Create Content" link (node/add) and can create interest groups all he wants.

Regarding the tree filtering issue, it seems that we might need to create a new function that does some custom queries to the DB and gets all of the appropriate groups to display in the parent field. I also think that we can forget about using the og_subgroups_get_eligable_groups() function because I think that is one of the things that limiting us. I don't think that function does what its supposed to do anyway: #1033114: Subgroups showing in subgroup tree block despite no access - MASSIVE FAILURE!!!

I'm thinking we might need a new recursive function that gets all of the top level groups first, then one by one retrieves the children for each top level. This way we don't have to worry about dealing with multiple group types because we only care about the group's children.

Does that seem like a good approach?

I have made some commits recently for other issues and the patch above will no longer apply properly. I have started working on a new patch that will properly roll with the latest changes. I am also going to re-work the existing patch to hopefully resolve our filtering issues described above.

here is an updated patch. I added quite a bit of new code in order to get the filtering to happen correctly. There is probably still some bugs and use cases to work out but we should be able to make forward progress again.

This patch satisfies the three use cases identified in comment #9 as well as the hierarchy illustrated in comment #24.

The only change to the UI is on the subgroup settings section on the node type form. I had to add a checkbox that enables or disables a group from being apart of a hierarchy because without it the logic was getting too messy. I also added a "Top Level" option to the "allowed parent types" field. I needed this so that I could distinguish between groups that could only be posted at the root level and the default groups that can be added as a child to all groups.

There's still more work to be done with this. I wanted to post what I had so it can get tested new bugs could get identified.

@capellic
I'm glad this is working for your use case. Let me know if you find any issues or bugs as this patch is still under development. Adding support for the Rules module is a great idea. Please create an issue for that and put as much detail as you can.

The "privileged users to create subgroups" section only controls the create link inside of the "Group Details" block. Any user role with the create permission granted will be able to create the groups through the standard Create Content (node/add) page.

For your use case you have a group that is auto created by some other means. Does this mean that you absolutely do not want any users, even site admins, to be able to create this group type? What if we changed the "nobody" option to "default" or "site admins".

I am unable to reproduce the issue you're having from #29. I set up two group types to be parents of themselves and when creating a new group as well as editing an existing node I only see the groups of the same type.

I have downloaded the latest dev copy and re applied the patch just to be sure there wasn't some code that didn't make it into the patch. It all works so far for me.

Can you confirm that you downloaded the latest dev build?

Here is an updated patch. I added support for Hierarchical select module, updated the Views integration, added code comments and added some descriptive text to the Allowed Parent Types field.

I have completely removed the "privileged users to create subgroups" feature. This feature is already available via the og_user_roles module. This module allows you to assign default roles to group admins as well as group members. The og_user_roles module can't assign roles to group admins and members for each group type, but thats where a patch should come in.

Please test and let me know what kinds of issues arise.

The functionality referenced in the original description of this issue has been implemented. The patches in this issue was to create extra functionality. This issue is now closed because the original requirement has been met. For a continuation of the development of the extra functionality mentioned in this issue, please see #1127856: Create ability to define a structured hierarchy between group types.