A restriction on which node types can be parent groups would be useful, in part to prevent circular parent\child structures. I hope to submit a patch for this in the next few days.

CommentFileSizeAuthor
#13 subgroupParentIssue.jpg43.61 KBsomebodysysop
#5 og_subgroups_relationships.patch10.85 KBezra-g

Comments

ezra-g’s picture

ezra-g commented
Title: Restrict which node types can be Parent Groups » Specific Parent-Child Group Relationships

I've coded up a simple configurable restriction to which node types can be parent types but it occurs to me now that it would be more useful to be able to specify exactly what kinds of node types can have parent->child relationships.

For example: Perhaps it makes sense for an event to be a child of artist and venue node types. Venue types can be parents and artists can be children, but it would not make sense for an artist to be the child of a venue.

Is that a clear example?

Are there any thoughts as to whether making the group node relationship definition part of this module or incorporating another node relationship module would be more appropriate?

At first, integrating with the nodefamily module occurred to me, but nodefamily requires the parent-child relationship to be set when parent and child nodes share a common author, which would not always be the case here.

ezra-g’s picture

ezra-g commented

I realize that my above example contradicted itself. I'm still working on this and hope to have a patch soon.

ezra-g’s picture

ezra-g commented

I'm still working on this...Hope to have a patch this weekend.

Question: Why do Group homepage nodes that are children of other groups not have a $node->og_groups array?

ezra-g’s picture

ezra-g commented
Status: Active » Needs review

The attached patch adds an OG Subgroups settings page which allows admins to configure which node types may be parents of an og_subgroup_node_type, as well as whether to show a 'set parents' and\or 'set members' form element.

This module also adds a og_subgroups_get_node_groups() function which uses the OG API to set the $node->og_groups and $node->og_groups_names arrays for og_subgroup nodes.

In creating this patch I discovered that posts inside of a subgroup do not show on the homepage of the parent group and aren't included in parent group new content notifications. This is something I'd like to add. I'll create an issue for it.

It would be great if anyone could review this patch. Thank you!

ezra-g’s picture

ezra-g commented
StatusFileSize
new og_subgroups_relationships.patch10.85 KB

It helps to attach the patch...

mohan.ka’s picture

mohan.ka commented

I have submitted an error report for this patch at http://drupal.org/node/121254. Maybe i have not done the patch properly. could you please follow up that and answer me and other like me?

swood’s picture

swood commented

I'm working on incorporating your changes into the current version. I hope to have something in the next few days for a release.

One question though: In your previous comment you stated: "In creating this patch I discovered that posts inside of a subgroup do not show on the homepage of the parent group and aren't included in parent group new content notifications. This is something I'd like to add. I'll create an issue for it."

Isn't this backwards? I would think that posts created in the parent would be visible within the children, but not the other way around. A subgroup is subset of a larger whole. I wouldn't think that posts within a subgroup would be visible by the entire group. If so, then there wouldn't be any privacy within a subgroup.

I believe that there are two rules that should work here:
1. Members of a subgroup are automatically members of the parent.
2. Posts within the parent are visible within the subgroup(s).

vikingew’s picture

vikingew commented

Yes I totally agree with #7, the other way around would kinda eliminate the purpose of subgroups.

I just had og and this module installed and experimenting, also being relatively new to Drupal, so I might just haven't get it right yet - but it seem to me now the member list doesn't get it right really. Like I currently have just for users on this site I am building and created a main Group with 3 of them as members, then a subgroup making the 4th a member of it, but when I click the members link in the main group only the 3 originally added are listed, I think the one from the subgroup should be listed here too?

Another thing, which may belong to another issue is that although I am uid=1 trying to access the subgroup (invite only) gives access denied. I think this should never happen for uid=1 ?

swood’s picture

swood commented

My intention is that members of a subgroup SHOULD appear in the primary group. This will take a little bit of doing though because the control is within OG. I made some changes to help with access but it's not quite complete yet.

As far as the uid=1 is concerned, that is also a problem within OG. There is currently no check for uid=1 for group access. I think that this should be presented as a bug to OG.

vikingew’s picture

vikingew commented

Agree, members of subgroups should appear in primary group, however that isn't the same as subgroup content automatically should show up in the primary group content - what's then the point of having a subgroup?

That said it doesn't mean subgroup content cannot show up there. I think first of all it's a question of if group/content is public or not, but still if I want content from the subgroup I subscribe and it only appear natural to me then I visit that subgroup to get the content. If content from the sub should shop up on primary it should rather be as a block type and not as a part of the main group content.

Having said this I realize this isn't really what this issue is about and discussion should really continue at http://drupal.org/node/145333 and get back on track about group relationships here.

somebodysysop’s picture

somebodysysop commented

I'm a little confused. I've got version 1.9 which, presumably, has the patch.

I see the set members and set parent settings and I have both checked. However, I do not see a set parent element on the group form either when I create it or when I edit it. Should I?

swood’s picture

swood commented

Make sure that you have the the 'Parent types' selected to the type of parent allowed. This is a new feature that allows you to specify legal parents of a group. If you don't select anything, then you won't see the option on the create/edit page.

somebodysysop’s picture

somebodysysop commented
StatusFileSize
new subgroupParentIssue.jpg43.61 KB

Attached is a screenshot of my og_subgroups settings page and an actual subgroup edit page. "group" is my only group content type. Nothing about parent groups on the group page. Am I missing something here?

swood’s picture

swood commented

The 'group' needs to be selected in order for this to work. The way this works now is that the subgroup configuration page defines what types of content are legal as parents of a subgroup. If nothing is selected, then you won't get the 'Parent' selection on your group page.

somebodysysop’s picture

somebodysysop commented

Right you are! Selected "group" and I see the "Parent(s)" selection menu. Sorry for not getting it sooner.

Thanks!

ezra-g’s picture

ezra-g commented
Status: Needs review » Closed (fixed)

Swood committed this patch in Rev 1.9 last May. Closing.

ezra-g’s picture

ezra-g commented
Status: Closed (fixed) » Fixed
Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

ezra-g’s picture

ezra-g commented
Version: 5.x-1.x-dev » 6.x-0.x-dev
Component: User interface » Code
Category: feature » task
Status: Closed (fixed) » Active

This feature should continue in the Drupal 6 version.

amitaibu’s picture

amitaibu
Primary language Hebrew
Location Israel
commented

As you are using the book hierarchy, you can't do any circular parent\child structures. I think it's should be wont fix, unless I'm missing something?

ezra-g’s picture

ezra-g commented

This feature wasn't solely to prevent circular hierarchies -- It makes sense for certain data types to restrict which types of groups can contain which others. For example:

If I want to create a hierarchy like
Country
--City
---State

I might want to make it impossible to have

City
--Country
---State

amitaibu’s picture

amitaibu
Primary language Hebrew
Location Israel
commented

In that case maybe you can make a function that will form_alter() the parents a user can choose in the book outline.

ezra-g’s picture

ezra-g commented

marked #369806: Propagation per content type as a dupe of this. 2 users asked for this feature on that thread.

tbenice’s picture

tbenice commented

i'd like this feature and might create something along the lines of #22. If so I'll post it back here. otherwise i want it on my dashboard so that I remember the suggestion ;)

ezra-g’s picture

ezra-g commented
Assigned: ezra-g » Unassigned

I am no longer working on this.

bschilt’s picture

bschilt commented
Status: Active » Closed (duplicate)

There is a working patch for this in the 6.x-1.x-dev branch: http://drupal.org/node/976042.