Subgroup visibility and access inheritance

We need modules of counties for each state that would populate subsites for each county, complete with support for forums, calendars, and other functions to be administered by local chairpersons in each county.

Perhaps someone else has done this, but so far I have not found them in searches.

We are seeking a solution for national organizations with state and county chapters.

What I am looking for has been implemented at several sites. For example, using Zoomla we have http://www.givemeliberty.org/#states but there was a lot of manual work involved in doing that one. It starts with a map of the U.S. Click on a state and one gets all the counties in that state. Then click on a county to get the county page. But that one doesn't have calendars and forums for each county,

Another implementation of the kind of thing we want is http://www.wildapricot.com but they want to host, and we want to do our own hosting.

The main site, which uses Drupal/CiviCRM, is http://lptexas.org

Please contact me at jon@jonroland.org if you have a solution.

Since content types can now be defined as group type and group content type at the same time, this should mean that subgroups are already an included feature. Visibility would then be handled by whatever node access modules Drupal 7 will have I guess.

Here's a quick patch providing a quick explanation above the installation guide. It also fixes a couple of mistakes I found.

***edit
Sorry, wrong thread. Can't delete my post or remove the attachment... Moved to here: http://drupal.org/node/820974#comment-3164868

Moving to OG prject, as OG will be the name in D7.

Maybe this module can help: Subgroups for Organic groups. They say:

This module allows users with the right access permissions to set group hierarchy.
Admin can set content and users propagation (...)

Subgroups are possible in OG7, but in order to propagate content/ users OG_subgroups7 should be used (In time of writing OG_subgroups7 doesn't exist yet).

Amitaibu wrote:
> Subgroups are possible in OG7, but in order to propagate content/ users OG_subgroups7 should be used (In time of writing OG_subgroups7 doesn't exist yet).

That's great news, thank you very much.

Please, what subgroup technique is OG7 using? A table like in in the new 6.x-1.x-dev version of the Subgroups for Organic groups module (similar to the D5 version, after they removed the D6 book dependency)? Or a taxonomy hierarchy, or nodereference, or another solution? Will it be reasonably easy to upgrade group hierarchies from og_subgroups6 to OG7?

I started on a simple patch for 6.x to handle subgrouping in a really simple way. After some brainstorming, I thought it would make sense to offer another node-type option for OG. By default, we have 'omitted', 'group', and 'group-post-standard'. Why not offer group-post-group, which acts as both a group node and a group post? Aside from adding this option, there's only a few places in the module that have to be altered. Basically whenever og checks for something like og_is_group_type(), we just allow the code to also check is it's a post type.

Basically..

Before:

if (og_is_group_type($node)) {

}
else if (og_is_group_post_type($node)) {

}

After:

if (og_is_group_type($node)) {

}

if (og_is_group_post_type($node)) {

}

It's really simple, it uses the existing og schema, and it works well. Obviously, I haven't yet dealt with the issues of permissions, access, membership, etc, but I think this is an interesting concept..

Thoughts?

Reminder: 6.x

Much improved patch. Contains recursive functions to create side-wide and group-wide hierarchical tree, including a cache mechanism.

Try it out

@mikestefff,
The issue here is about OG7. Are you proposing this patch as a concept for og7?

No - just didn't think you'd want a duplicate thread about the same topic. Thought you'd be interested to see this approach. I wanted to hear any thoughts you might have.

subscribing

subscribe...

fyi #935178: Port og subgroups to Drupal 7

subscribe

Any update on when this subgroups module will be available for D7?

Thanks

Glenn

@mikestefff,
Sorry for the late reply, I was working hard on og7 (I plan to have a new release soon).

I actually think this patch doesn't belong in OG core, there's too much logic around the idea of subgroups. One of the problems is the og6 is designed to explicitly *not* allow group to be child of another group. I'm not even talking about the fact that you can't have a group inside {og_ansectry} table, but the fact there is no proper permissions system, doesn't really let you do anything with this hierarchy.

OG7 was designed with subrgoups in mind so #824016: Subgroup visibility and access inheritance can be accomplished without the hair pulling.

I know D6 is here, and it will stay around for some time, but I wonder if OG7 is an option for you?

@Amitaibu, now that there's a dev release for 7.x of http://drupal.org/project/og_subgroups, should we mark this issue as closed? If porting og_subgroups to D7 is the solution, let's direct people there to provide feedback.

Marking fixed, as og subgroups is now ported to d7. Thanks Amitaibu! ;)

What about subgroups for 7.x-2 ? Code of the new version is really changed and I'm not sure if og_subgroup is working with it.

Yes, at least somebody is: #1536178: Integrate with og-7.x-2.x.

how to make a views that contain content added to the all subgroups - on parent group page via panels - ?
and how to make - if member jpin to the parent group he can receive all massage about content added to the subgroup ? any solutions ?

This definitely seems to be living in og_subgroups at #1536178: Integrate with og-7.x-2.x so 'won't fix' this issue.

This definitely seems to be living in og_subgroups at #1536178: Integrate with og-7.x-2.x so 'won't fix' this issue.

I am reopening this old OG issue and moving it to OG Subgroups because #s 1 and 2 seem to me to be integral parts of subgroup functionality. If I have a private group that contains subgroups, it seems completely illogical to me that those subgroups should be visible outside the parent group.

Also, as the OP points out, this would allow for the creation of a Members Only area, where some subgroups may be private to members of the subgroup only where others are accessible to all members of the parent group, but not to the general public.

This is exactly my use case:

1. Parent group: School — Private. Accessible only to members of the school community.
2. Subgroup: Parent council — Public to members of the School group only, not the general public.
3. Subgroup: Parent council executive committee — Private. Accessible to executive committee members only.
4. Subgroups: Grade 1, Grade 2, etc. — In an ideal world, we'd have the capability to allow all members of the School group be able to view this content, but only members of each grade group could post content.

@mpotter, who I know is working on this module for Open Atrium 2, refers to this in #2051597-7: Support to 2-way user inheritance on 2.x but mentions that that access inheritance should probably be separated into a different issue from user inheritance. So I am hoping we can discuss the issue of access inheritance here.

I'm interested in offering some funding to support the development of this functionality if anyone with the skills to code this also has the time and interest. Please contact me through the d.o contact form if you might be interested and let me know what you think it would take.

— Kelley

I have been working on BrightBold's request, and I decided to temporarily implement the Access Control part as a standalone module (hopefully can be included as a patch). This module depends on a pending patch right now #2407399-2: Access only checks one level deep.

Module is a sandbox project https://www.drupal.org/sandbox/liberatr/2449227

This module assumes the following:

1) *use group default* is private for public group whose parent (or grandparent) is a private group, private for private group, public for public group. This is the only change this module implements.

2) *public* content is public to the world - default

3) *private* content is private to the group - default

How about this:
1.normal public
2.normal private
3.private, but public to parent group
options: up [ one , two , 9999 ] level deep
options: parent group's member act like current group role 'whatrolespecify'.
options: parent group's member act as parent group role 'whatrolespecify'.
options: parent group's member act as parent group's own role .
4.use group default. base on parent group, public to public , private to private.
options: up [ one , two , 9999 ] level deep
or : specify control group for control current group's privacy.
options: parent group's member act like current group role 'whatrolespecify'.
options: parent group's member act as parent group role 'whatrolespecify'.
options: parent group's member act as parent group's own role .

What I need to achieve is this:

- Grandparent group
-- Parent group
--- Child group

Members of a grandparent group can see all groups and all content for all 3 levels under that group.
Members of a parent group can only see content of that group
Members of a child group can only see content of that group

Would my use case be solved by this issue or am I in the wrong place?

Has anyone ever found a solution to this?