Postponed (maintainer needs more info)
Project:
Subgroups for Organic groups
Version:
5.x-4.0
Component:
User interface
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
11 May 2008 at 19:30 UTC
Updated:
2 Sep 2008 at 06:47 UTC
Jump to comment: Most recent file
Comments
Comment #1
ezra-g commentedPlease let us know if this happens with the 5.x.4 release which will be available in a few minutes.
Comment #2
rbryer commentedI have tested in 5.x.4 and I now have the Set parent option.
I'm not sure that it should be on a tab called 'Subgroups'. But I'm not sure what I would call it.
But it seems to work, Thanks.
Comment #3
EmpireNM commentedJust installed version 5.x-4.0 of this module and trying to figure out how it works. Maybe this is part of my problem. I didn't see a "set parent" option when creating a group. So far I don't understand how to assign a group to a parent. I've looked at the subgroups tab of a particular group, but in the drop-down option, I only have "top-level" available.
Thanks for all the great work.
Comment #4
EmpireNM commentedSorry, I'm trying to understand this as best as I could. This would be a very useful module if I can get it to work. So want to thank you in advance for the great work.
I finally found an option in the OG User Roles config to "Create link to "Create Subgroup" in group menu?". But in the Subgroups block, the subgroup is not showing. Each group merely lists itself as a subgroup. I also tried the cope snippet the hide the block if there are no subgroups, but then I get nothing at all, even though there is a subgroup now created.
Maybe I have to assign it after I've created it? Sorry, but I don't understand what the "subgroups" tab is for. All I see is a "top level" option, so I am unable to assign it to anything.
Thanks again.
Comment #5
amitaibu1. AFAIK the OG user roles is not updated with the 5.x-4.x release which is a complete rewrite of the previous release.
2. Create several groups then in the select list you should see not only but also the other groups.
Comment #6
ravi_sam commentedI had the same problem as dlivingstone.
On examining the module code, I noticed that there is a call to 'og_node_groups_distinguish()' from 'og_subgroups_get_eligable_groups()'. The former function (of og.module) has an undesirable effect of excluding groups in which the user is a member. This results in exclusion of groups created and administered by the user. This is the reason the select shows only '<top-level>', if the user happens to be the admin for all groups.
I have fixed this error and am attaching the patch. Thanks to the authors for a great module.
Comment #7
ezra-g commentedChanging status
Comment #8
amitaibuWas out of town, I'll review this patch in the next few days.
Comment #9
amitaibu@ravi_sam,
As we are using in the og_node_groups_distinguish()
$exclude_joined=FALSEwe get all the groups the user is a member/ admin.It seems your patch simply duplicates the og_node_groups_distinguish() - or am I missing something there?
Comment #10
ravi_sam commentedAmitaibu,
I installed the og.module a few months ago and looks like it is slightly older version (5.x-6.1) in which the og_node_groups_distinguish() does not take a second argument of $exclude_joined. So, the line
gets applied irrespective of the FALSE value on the second argument. You are right that my patch duplicates og_node_groups_distinguish(), but without the above line. I guess the present og_subgroups.module code should work fine with the latest version of og.module, in view of the facility to specify $exclude_joined as the second argument.
Comment #11
amitaibu@dlivingstone,
What og.module version are you using? Can I mark it as fixed?
Comment #12
somebodysysop commentedNote:
Re #5: OG User Roles has been updated and version 5.x-3.3 release will reflect support for latest og_subgroups 5.x architecture.
Comment #13
amitaibu@SomebodySysop, cool thanks.