I want to know whether the following configuration should be possible with OG 7. Here's what I'd like to do:

  1. Parent group, "School," is a private group, only accessible to group members.
  2. Content type for "Grade" is set to be both a group type and a group content type and the group audience is set to "School" so that all Grades are subgroups of the School group.
  3. Ideally, I'd like the Grades and all their group content to be visible to everyone in the School, but only members of a Grade can create group content within that grade.

I tried setting the School to private and the Grades to public, thinking the subgroup content would only be public to members of the parent group, but if you do that it appears to be public to everyone. (I do have the OG Subgroups module installed.) So is there a way to achieve this? Or should this be working and if so, any thoughts on what I might be doing wrong? Thanks.

Comments

zzadik’s picture

zzadik commented

subscribe

amitaibu’s picture

amitaibu
Primary language Hebrew
Location Israel
commented
Project: Organic Groups » Subgroups for Organic groups
Version: 7.x-1.1 » 7.x-1.x-dev
Component: og.module » Code

Correct project

brightbold’s picture

brightbold
she/her
Primary language English
Location Boston, MA
commented

Thanks - it's helpful to know that OG Subgroups would be required to make this happen. If anyone knows whether this is possible and if so, how to achieve it, I'd love to know!

paul2’s picture

paul2 commented

Hi @BrightBold. I too have been looking for this feature in OG7, coincidentally for a similar application (my client is also a learning institution, and they have a course->class relationship with similar requirements as your school->grade relationship; members of any of the "class" nodes should automatically become members of the parent "course" node). I've actually spent today and yesterday implementing this functionality in og_subgroups, and have at least got as far as membership subscription working, in either the parent or child directions (as you can specify).

Things that I haven't got working yet are:

  • propagating membership type updates or membership state updates in the same way (though it won't be hard to do, it's just not a priority for me yet)
  • propagating membership removal in the opposite direction; i.e., if membership is propagated to the parent, then naturally membership removal from that parent should be propagated back to the child

I'm going to post my patch even in its incomplete state, since it still could be useful to you. However, it is based on patch #25 in #1226002: D7 subgroups: Control direction of content/membership inheritance, and it is really part of that same feature (inheritance), so I'm going to post it there.

brightbold’s picture

brightbold
she/her
Primary language English
Location Boston, MA
commented

Thanks @Paul2 — I'm following the other thread as well so I saw your patch. This looks like it will be very useful! I'm hoping to spend some more time this month working on the site where I wanted this functionality, so I will post back in the other thread when I get a chance to test your work. Thanks for working on this!

paul2’s picture

paul2 commented

Just thought I'd post an update:

I discovered that some shortcomings in OG7 stable's current incarnation make it difficult for subgroups to work. In patching og_subgroups I discovered that there were major conflicts happening between user membership and group hierarchy (they both shared the same field instance). It means you can't really use og_subgroups with OG7 stable yet, so I would avoid bothering with the patch I posted for now.

Amitaibu has been working on a fix for this but it requires #1342632: Deprecate OG group entity to be done first, which changes the OG API significantly. I adapted my version of og_subgroups to Amitaibu's branch, but I just focused on the feature that I need right now and left the rest of og_subgroups commented out, so I'm wary of posting a half-assed patch. Let me know if you really want to try it out and I can send you the new patch.

brightbold’s picture

brightbold
she/her
Primary language English
Location Boston, MA
commented

Thanks @paul2 — I've been waiting for #1342632: Deprecate OG group entity to shake out as well, so I will wait until you can post a complete patch and test it then. I agree it makes sense to have the full OG Subgroups functionality if possible.

memoo’s picture

memoo commented

sub

brightbold’s picture

brightbold
she/her
Primary language English
Location Boston, MA
commented

In #1536178-80: Integrate with og-7.x-2.x, @kenianbei says

Content in a parent isn't inherited, nor is content in a subgroup inherited upward to the parent. If there is a use-case for this we can add it, since I've written the code already. Just open an issue in the 7.x-2.x branch.

So above is a use case for upward inheritance of content. However what I was specifically asking for in the above is whether there could be inheritance without editing rights - so that if I'm in the "School" group and the "3rd Grade" subgroup, I can view items from the 4th Grade subgroup, but I don't have the same permissions that I might have for other items in the "School" group. Is this possible? Or do I need to rethink my site plan?

Edit because I said down when I meant up

markdc’s picture

markdc
Location Selters
commented
Issue summary: View changes

Has there ever been any progress on this? This is exactly what I need.