Currently, when I create a new Group, I have a box "Subgroups" to choose from.
What imho would be a good thing is to have is a box "Parentgroup(s)" to choose from.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | og_subgroups.patch | 5.93 KB | swood |
Currently, when I create a new Group, I have a box "Subgroups" to choose from.
What imho would be a good thing is to have is a box "Parentgroup(s)" to choose from.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | og_subgroups.patch | 5.93 KB | swood |
Comments
Comment #1
codewatson commentedI'll second that, it seems backwards to create all the children first, then create the parent and in the parent tell it what children it has, seems like the whole egg before the chicken quandary..
Comment #2
swood commentedI agree with you. When I first discovered and started using this module I thought the same thing. Now that I have inherited it, I'm going to do something about it. I just haven't had the time time yet.
One concern that I had though concerns access rights. It will be necessary to restrict the list of parents to only those that the user has rights to.
Comment #3
fronbow commentedI would agree here, it seems a bit backward to have to define the children before defining the parent.
It would be a lot better to set up all the parent groups then to add children.
Comment #4
indepth commentedI agree with you too. We usually build parents first then children, not the other way around.
Comment #5
swood commentedI am planning on resolving this problem but have had other more pressing concerns. If anyone is willing to propose a "fix", I would be more than happy to look at it and apply. Otherwise, it may be a little while.
Comment #6
ezra-g commentedI would be happy to discuss what would be involved and contribute a patch. I'd really like to get this going soon. So if anyone has any thoughts about what is necessary to implement this feature, I'd be glad to hear them.
Comment #7
ezra-g commentedRegarding #2: Could one do a user_access() on each node before adding it to the list of available nodes in the form?
After looking at this module I wonder: aside from the access check, generating the input to accompany the functionality and creating\changing an entry in the og_acestry table, is there anything else that's really necessary to set a node as the child of another node?
This would be good to know as I'm very interested in contributing a fix.
On a side note, it would be nice to have a Nodereference field for each parent group node type as an alternative to a list of checkboxes.
Comment #8
swood commentedI have modified subgroups to have a Parent(s) box in the edit form. This will allow you to select the parents of a particular subgroup rather than the children. I left the subgroups tab alone so you can actually do it either way. The main edit form allows selecting the parent, while the subgroups tab form allows selecting the children. In addition, I have added a 'edit subgroups hierarchy' access control permission. This will allow you to define which groups can establish and modify the hiearchy.
I have recommitted the code and it should be available by tomorrow. For those that can't wait, I have supplied a patch.
Comment #9
ezra-g commentedThank you! I actually started working on a patch to do this last night and was surprised to see it here this morning. I am thinking of adding a settings page for this module that allows you to restrict which node types can be subgroups, as well as whether you wish to have the option to set parents, children, or both.
Comment #10
swood commentedA settings page would be a great idea. I was thinking about it but just haven't had the time. Are you wanting to have the ability to set both the parent and children on the edit form? This should be fairly easy to do. A block just needs to be added back to the form for setting the children. I would think though that this would be something that is configurable.
Comment #11
ezra-g commentedI'd like to be able to choose whether one can set the child or the parent. Yes, it sounds like something that should be configurable. Thanks so much for this patch! It really sets things in the right direction :-).
Comment #12
ezra-g commentedI've added this configuration option in my patch at http://drupal.org/node/143530.
Comment #13
mohan.ka commentedhi this is to bring to your kind notice that i am not able to use the patch you submitted. I am not sure if i did the patching process correctly. i downloaded og_subgroups.patch and patched it in linux shell command. i got this message:
mohankalai@mohankalai:~/og/new$ patch og_subgroups.module og_subgroups.patch
(Stripping trailing CRs from patch.)
patching file og_subgroups.module
Hunk #9 succeeded at 487 with fuzz 2.
once i uploaded the new file in og_subgroups folder, i cannot access my site.
Browser says: Internal Server Error. Only after i replace the original file (unpatched file) i am able to access the site.
id of original file reads "// $Id: og_subgroups.module,v 1.7 2007/02/14 19:12:53 swood Exp $"
i dont know where i did wrong. could you please help me. i also tried og_subgroups_relationships.patch. i get error in that patch also. i am a new comer to drupal. so please explain if i should apply these two patches in any order. can i apply both patches to og_subgroups.module?
i am working on a social network site in which user needs to create subgroups of existing group. the default og_subgroups doesnt give me that option. After reading your node, i thought it was great and would solve my purpose. but unfortunately i could nt able to use the patch. can you upload a patched file? there may be many like me who fail to patch correctly.
thanks for all the help you do to the drupal community.
Comment #14
swood commentedEnhancement made to 5.x-2.0 to select Parent instead of Children. Administrative page has been added to control whether parent option appears on form. Thanks to ezra-g for contribution.
Comment #15
(not verified) commented