This bug current exists in both the beta3 branch and the dev branch as of Sept 1st 2011.
I have 2 group content types set up, the first is being used as a location (parent, where other groups will gather) and the second is to be used for the project groups (child) that will gather at the parent location. I have the location group set to having subgroups allowed in the SG config.
In this case if I attempt to create a location group, I see the parent group dialog box, but there are no available groups listed. I have several hundred of the location groups already set up, so there should be something there. If I attempt to create a project group, there is no parent group dialog to be seen.
If I also mark the project group as being able to have subgroups then when creating either group type the parent group dialog shows, but only allows the project groups to be parents, i.e. no location groups are available.
Without diving into any kind of structured hierarchy, in the case of the first case above, there should be a parent group dialog when creating both types of groups, but only location groups should show (per the checkbox in the SG configuration settings)
Comments
Comment #1
bschilt commentedI am not able to reproduce the behavior that you are describing. I have installed a fresh copy of D6.22 with the latest OG, Views, OG_Subgroups and Devel modules.
- I created two groups, Location and Project.
- I then used Devel to generate 10 Location nodes.
- On the OG Subgroup settings page I enabled subgroups for the Location content type only.
In your first case you said that Location nodes were not showing up in the parent selector. In my test case they were.
- Next I enabled subgroups for the Project content type.
Now when I create either a location or project, both node types show up in the parent selector. Whereas your location nodes where not showing up.
So...You'll need to make sure that both project and location content types are selected on the OG Subgroups settings page in order for them to show up in the parent selector. Double check that the content types have the "Group Node" selected on the content type settings page, (although I'm sure it is). Make sure your location groups are not 'private'. You also may want to try and use User 1, maybe it a permission thing.
I think something isn't quite right with your location nodes, maybe try setting up a sandbox site and re-create your use case on a fresh install and new nodes. Just to try and identify if its a problem with the module or your content type.
Lastly, each group is run through a masking function to make sure the current user can view it. Maybe the groups are being stripped out due to some condition. In order to eliminate the masking function as the culprit, make sure your user has 'administer nodes' permission. Pasted below is the masking function, its well documented.
Comment #2
Dixen commentedBrian,
Thank you for the help.
I was using User #1 for all testing, so that user permissions shouldn't get in the way of anything (I had also updated user permissions just to be sure).
Everything else you noted was set correctly, but in the testing it did lead to discovery of the problem. The content types being used for groups are "conversions". They were just ordinary nodes until being converted to nodes ... in the process of my own testing I created a test node type, then created a content item, then converted the node type to a group node, then created another content item. The second, post group conversion node showed up in the parent group selector, while the pre-group conversion node did not. This means that "group" nodes are not being flagged as nodes until they are updated at some point after the node type is set to be a group and is then re-saved.
Comment #3
bschilt commentedI'm wondering if this is a caching issue. The list of parents are retrieved from a cached copy of the subgroup hierarchy. The hierarchy cache is cleared when a group is created, updated or deleted so in your case the cache *should* be cleared when the conversation node is converted to a group.
Try clearing Drupal's cache at admin/settings/performance. In the mean time I'll try reproducing the behavior you're mentioning.
Comment #4
bschilt commentedIts not a cache issue, I was able to recreate the problem you are having. Here is my summary of how to recreate it:
1. create a new node type, lets call it 'Test Group'. DO NOT make it a group node yet and do not adjust any Subgroup settings.
2. create two or more standard nodes from Test Group. Call them Pre Test 1, Pre Test 2, ...
3. Now edit the Test Group content type and make it a Group Node.
4. go to Create Content->Test Group and create another Test Group node and call it Post Test 1.
5. go to admin/og/subgroups and enable subgroups for Test Group.
6. go to Create Content->Test Group and look at the parent field, only the Post Test node shows up. The Pre Test nodes are missing.
This isn't an issue related to the Subgroups module, this is something that OG should handle when converting an existing content type into a group node. I imagine OG doesn't update existing content due to group privacy settings.
The trouble is that there is no record in the OG database table for the existing nodes (the pre test nodes). The easiest solution is to go to admin/content/node and filter by the content type having the issue. Select all nodes and run the Publish bulk operation. This will cause each node to be resaved and OG will then add a record in the OG table. Then all of the "pre test" nodes will show up in the Parent selector.
Comment #5
Dixen commentedBrian,
I did realize that this was an issue with OG rather than SubGroups after I posted. My apologies and thank you for the fix; I will post a, issue to the OG queue as well.