D7 subgroups: Control direction of content/membership inheritance

+1

Subscribe. This is mysterious to me as well.

Are group a and b private?

I have tried this with both groups private as well as with group A private and group B public, but still can't figure out how I'm supposed to configure this.

Also, I'm really hoping that, as implied in the title of this issue, this module will allow you to control direction of inheritance. The README for the module implies that it's a top-down inheritance, but what I want to do is ensure that every member of any subgroup (an elementary school grade) automatically becomes a member of the greater school community, while people who aren't part of the school community can't see private content. Should inheritance work in both directions, or is that not part of the module?

> Should inheritance work in both directions, or is that not part of the module?

It should, but currently it doesn't.

> it's a top-down inheritance

Not sure what you mean, so just to clarify -- the permissions is granted if the user has permission in on of the *parents* group.

Hi there,

I've updated the module a bit, here are the new features:

- You have a simple UI to choose on which entity group type you wish that subgroup is working
- You can as well choose if you want to behave on children or parents... or both of the same hierarchy
- You can also add a field throug the OG admin to choose a specific behaviour for each nodes
- Readme.txt includes an explanation to use this module

N.B I also corrected a potential bug occuring when you selected a group as a group content of himself and making an endless loop.

Hope these features may help somebody and if so, why not ask to include it in the core?

Cheers,

Fred

Thanks lahode, sounds great! I will try to test this soon.

Hi Brightbold,

Thanks for your reply. Here is the last patch I made, it's maybe better than a zip and a reviewed a bit my code.

Cheers

+++ b/README.txt
@@ -1,11 +1,20 @@
+The Organic Groups Subgroups module (also referred to as the 'og-subgroups' ¶

README stuff should probably be in another issue. Also note the trailing whitespace.

+++ b/og_subgroups.info
@@ -3,9 +3,10 @@ name = Organic groups subgroups
+dependencies[] = og_ui

Why is it dependent on UI?

+++ b/og_subgroups.module
@@ -1,9 +1,87 @@
+define('OG_SUBGROUP_FIELD', 'group_subgroup');

Lets call the field og_subgroups_direction

+++ b/og_subgroups.module
@@ -18,6 +96,80 @@ function og_subgroups_ctools_plugin_directory($module, $plugin) {
+      if (is_array($graph) && module_exists('graphapi')) {

I know this was in the original patch, but we definitely need to move this out. Probably in a follow up patch.

+++ b/og_subgroups.module
@@ -96,7 +249,9 @@ function og_subgroups_og_user_access_alter(&$perm, $context) {
+  /* TODO: Check if this function is still usefull */

What's this TODO?

+++ b/og_subgroups.module
@@ -132,9 +287,23 @@ function og_subgroups_node_access_records_alter(&$grants, $node) {
+    // Get node behaviour

Why assume only nodes? This can be any entity.

+++ b/og_subgroups.module
@@ -132,9 +287,23 @@ function og_subgroups_node_access_records_alter(&$grants, $node) {
+    $subgroup_behaviour = variable_get('og_subgroups_propagate_content_node|' . $node->type, array());

Why use variable -- we have this info in the field, no?

+++ b/og_subgroups.module
@@ -168,40 +338,19 @@ function og_subgroups_grants_has_og_realm($grants) {
+function og_get_all_contentgroups($entity_type, $bundlename, $gid) {

function name must be og_subgroups_ ...

$bundlename => $bundle_name

Also, please document all variables.

+++ b/og_subgroups.module
@@ -168,40 +338,19 @@ function og_subgroups_grants_has_og_realm($grants) {
+  $query = db_select('field_data_group_audience', 'ga')

What are we trying to do here? I'd rather do it with fieldEntityQuery if possible, rather than db_select()

Powered by Dreditor.

Hello Amitaibu,

First of all thank you for your prompt reply and your comments! Nicely meticulous, exactely what I like!

Here are my answers and please find the latest patch:

- README stuff should probably be in another issue. Also note the trailing whitespace.
Ok, fine for me. I reviewed all the module with coder, it should be fine now

- Why is it dependent on UI?
I made it dependent on IU, because if no

- Lets call the field og_subgroups_direction
Changed!

- I know this was in the original patch, but we definitely need to move this out. Probably in a follow up patch.
I removed everything linked to graph module in the code

- What's this TODO?
I don't know that's why I put it. Finally, I removed this function because OG subgroups is working great like that

- Why assume only nodes? This can be any entity.
Then why "function og_subgroups_node_access_records_alter". I didn't any hook_entity_access_records_alter, only found a post somewhere saying that this would maybe be implemented in Entity API

- Why use variable -- we have this info in the field, no?
Because they are defined in the OG subgroups admin, please look at og_subgroups.admin.inc file

- function name must be og_subgroups_ / $bundlename => $bundle_name
Changed!

- Also, please document all variables.
You mean the variable_get(… ? Or all of them? Are you mentioning the @param?

- What are we trying to do here? I'd rather do it with fieldEntityQuery if possible, rather than db_select()
Totally right, that's what I did. However, I could do that in the includes/tree.inc file, because of an issue related to fieldEntityQuery

I also made some tuning and started to implement og_subgroups_views, although it is not working now and I still wonder if conceptually og_subgroups_views should belong to og_subgroups as it was done in D6.

Cheers

Strange, the last patch only included my new files but not the changes I made to the existing file.

I'm more a Window user, so I'm quite new with git

Please find attached the changes

Hello again Amitaibu,

Third try, I finally understood how git is working...

Here is the list of modifications included in this patch:

Added a UI to choose in order to select which entity bundle can be included by subgroups and also being able to rebuild the rights without needing to modify each one of them (that's why I made OG UI required, because by default OG subgroup is disabled)

Removed the Ctools graph option

Removed the og_subgroups.test file

Removed the hook_og_user_access_alter() that seemed to be useless

Added the ability to give permissions to all children group contents (initially it was done for parents only)

Added OG_SUBGROUP_DIRECTION field, so that each group content can have different directions (this is managed through OG UI access)

Added og_get_hierarchy() function to retrieve a nested or flatten view of the hierarchy, see tree.inc

Added sorting by hierarchy option for Views module

Added argument hierarchy option for Views module (unfortunately not working, it says "Broken/missing handler" and I don't know why, you do maybe?)

Well I think that's all, it answers my needs and hope may do for others. Do not hesitate to comment my code like you did before, I would be glad to make some corrections and I really hope my work will be taken in consideration for a new version of OG subgroups.

Cheers

1st: download and untar http://ftp.drupal.org/files/projects/og_subgroups-7.x-1.x-dev.tar.gz
2nd: download and untar http://drupal.org/files/issues/new_files_to_add.tar_.gz
3rd: download and apply patch: http://drupal.org/files/ogsubgroup_ui-1226002-15.patch

So the question is, are these steps ok, if so, when applying the patch is this ok?:

......modules/og_subgroups# patch < ogsubgroup_ui-1226002-15.patch

or I should apply it from somewhere else?, where?

Thanks for your help.

Ok, yes, this is the way to do it, when applying the patch you will see next messages:

The next patch would create the file og_subgroups.admin.inc,
which already exists! Assume -R? [n] y

The next patch would delete the file graph.inc,
which does not exist! Assume -R? [n] y

As you can see, in both cases the answer is "y" (yes)
Then enable the modules "OG subgroups views integration" and "Organic groups subgroups", then your done.

Sorry, probably I should post this in here:

http://drupal.org/node/1322590

I continue experiencing the same problem with whatever kind of content that I try to create, and at last the content can not be created, I've tryed uninstalling the module og_subgroups but the problem persists. Please some help!

Desabling og_create_perms module the problem is gone, but enabling it again, the problem comes back.

Ok, I could finally restore the way mi site behaves well, and now I can tell that the problem comes after doing this:

- Go to admin/config/group/fields and add to the new content type the following fields: "Groups audience", "Group content visibility" and "Subgroup behaviour"

- Go to admin/config/group/subgroups and check the content type. Then, select if you wish to have a default global behaviour

From then on I can not create any new content,

Besides, when I log out, I got this message:

EntityMalformedException: Missing bundle property on entity of type node. in entity_extract_ids() (line 7405 of .../includes/common.inc).

some support please.....

@Andres Chandia:

Yes you should definitely post that information in another issue! This issue is about the UI for the module and setting a direction for the inheritance. When you change the title, category, and other fields you are changing the entire issue to be about something new, which is not helpful to people who are following or working on this issue or to people who may be having similar problems and are searching for a solution.

You seem to have a number of different problems here which apply to several different modules, so if you are still needing help you should create NEW issues for those in the appropriate places. But remember to do a search first — often you will find that other people have already encountered the same problem. For instance, I have also been experiencing EntityMalformedException errors so I know there are existing threads on that problem; you should search all of drupal.org because it may be triggered by things other than Organic Groups.

Hello,

Finally I decided to split the View part from my patch #15 in 2 different modules. Although it was incorporated in D6 with og subgroups, OG audience field didn't exist either and there is no more reason to put together user right functionalities with Tree Views option.

For that reason, I took of everything related to Views and created the following module: OG Tree Views

The patch below contains only what is properly in relation with OG subgroups + the UI

For your information, I created a tutorial that explain how to easily put in place everything, please find it on the following link if interested: How to manage the concept of hierarchy for your Intranet

Hope all these information will be usefull.

Cheers

Sorry ogsubgroup_ui-1226002-24.patch is a wrong patch. Try the one below:

I see you removed all the tests, why?

Well, I wanted to clean the module and was not sure the test worked with my patch.

But you're right it's better to keep the tests.

• Any plan for a new dev release?
• I saw this post http://drupal.org/node/1317164, would it be interesting to incorporate the functionality (allowing parent/child users to manage groups) to OG subgroups?

A last question a bit apart, concerning my #24, wouln't it be better to merge my OG Tree Views module to Organic groups views, to be able to display hierarchized groups?

Hi lahode,

What are the steps to apply patchs ?
og_subgroups.zip + new_files_to_add.tar_.gz + ..1226002-1.patch + ..1226002-13.patch + ... + ..1226002-25.patch

or same like #17
og_subgroups.zip + new_files_to_add.tar_.gz + ogsubgroup_ui-1226002-15.patch + ogsubgroup_ui-1226002-25.patch

or just
og_subgroups.zip + ogsubgroup_ui-1226002-25.patch

I tried all possibilities and many other, but always it's failed... How may I have to do ?

EDIT :I found by myself
just toke the version in OG subgroups and not og_subgroups.zip

Thanks for your work,
Regards,
Jo

Hi again,

The tree view widget don't work for me.
I found that the value that you pass for check-boxes tree are the node id of the group, but I think it's the gid that it must be save.

Create some nodes without group.
Add a new unit (in ref to your video tutorial) normally gid and nid will be differents.

Look now the difference in table "og_membership" when you save the audience with the OG audience widget (it saves gid) and the tree view widget (it's nid).

In my case the group's nid was 73 and his gid was 1 . I understand why that doesn't work. If I change directly the value in the database that's ok !

But I didn't find where I can change this in the code to make test.
Can you try to recreate my case to check if I'm right.

Jo

Hi Jo,

First for #28, you need first to take OG Subgroups from http://drupal.org/project/og_subgroups/git-instructions and then apply patch #25, but I you wrote below you already found the way.

#29: Not sure I understood everything. Are you talking about OG Tree Views (http://drupal.org/node/1325062) and Entity Reference Tree(http://drupal.org/sandbox/lahode/1325398)?

If yes, please post directly your comments on the module related, so it's easier for everyone to identify the issue
If no, please read post #24

Hi,

I think it's about OG tree Views
so I opened a new issues here
http://drupal.org/node/1359508

Jo

maintainer(s): please apply patch in #25 to dev version.

@Iahode: thank you very much for your work.

maintainer(s): please apply patch in #25 to dev version.

@Iahode: thank you very much for your work.

.

I've just begun to implement membership inheritance for D7 OG Subgroups, to add to the great work lahode has already done for content inheritance. The attached patch adds another section to the subgroups admin UI screen to configure membership propagation, similar to lahode's settings for content propagation.

The implementation is incomplete, as membership is only propagated to parents/children (as desired) when you add a member to the group. What still needs to be added is the following:

• membership propagation triggered when a subgroup relationship is made
• propagation of changes (updates) to memberships (e.g., type and state)
• propagation of membership removals

My patch is not dependent on any other patches and it includes all of lahode's contributions. Just use git to checkout the latest from the 7.x branch, then apply the patch.

Hope this is useful to some people.

@paul2: Your patch does not include og_subgroup.admin.inc, although you mention it adds another section to the subgroups admin UI. Missing file ?

Also, when adding the Subgroup membership propagation direction field I get :
FieldException: Attempt to create a field with a name longer than 32 characters: <em class="placeholder">group_subgroup_membership_direction</em> in field_create_field() (line 70 of /Users/jide/Sites/extranet/htdocs/modules/field/field.crud.inc).

Hi @jide. It turns out that my patch isn't actually very useful yet, as I discovered that OG7 stable in its current incarnation does not allow relationships of groups to other groups and users to groups to play well together. As I was playing around with it I discovered major conflicts occurring when I tried adding users to multiple groups while at the same time retaining the parent group relationship. So I wouldn't recommend trying it just yet. It seems that the only way forward is via @Amitaibu's route here: #1342632: Deprecate OG group entity. My current work on og_subgroups is now based on that OG branch.

As for the weird patch issues, I'm surprised git didn't include og_subgroups.admin.inc... or any of the other files I changed. Maybe I'm not using git properly? I just changed files, then ran git diff > ... like it says on the Version control page.

Thanks for pointing out the 32-character limit bug. I guess I never actually tested that part of it! My bad. I'll be sure to fix it.

Hi again @paul2. Agreed, the ongoing work on refactoring OG makes it hard to actually move forward on anything OG related for now. So I guess that's a good idea to wait for this to move on before.

For the GIT issue, the best approach is to use branches, that is make a new branch, and then create a patch that diff-es the two branches. You can see how to do this at http://www.jide.fr/english/creating-git-patches ;)

Anyway, thanks for your work on this, this module definitely needs some love.

Subscribe.

@paul2 can you clarify the issue where you "discovered major conflicts occurring when I tried adding users to multiple groups while at the same time retaining the parent group relationship" ?

would like to help resolve (patch) this with you if you can be more explicit with the code you're referring to.

Well, this was back with the dev version of OG 7.x-1.x, and OG has changed quite a bit in 7.x-2.x. That issue I was referring to is no longer relevant since the "group" entity has been deprecated in 7.x-2.x. I have a new version of OG Subgroups compatible with OG 7.x-2.x that does the bare minimum of what I need it to do. I'll see if I can post a patch for it shortly.

sticking with 1.x for the moment, since pretty much all the stable og code out there is levered to og 1.x...

one of the issues with the membership patch (#34) is that when adding a group content node, prior to saving that node, it has no place in the membership tree. once its position is set in the membership tree, only then can membership propagation have any meaning...

there is a potential catch with this. the group audience field is populated only by the groups a user is already a member of. in the case when the node being added is to propagate membership to other groups the user is not yet a member of, and one of those groups is to be one of the group audience nodes, a virtual catch-22 is had.

so, what hook to use that would be invoked whenever the group audience fields widget is loaded for a node add or node edit ?

I'm using Organic groups 7.x-1.3 and I've checked the 'Parent' check box for propagation, but when content is added to the subgroups, it is not propagating to the parent group.

Do I need to upgrade to OG 7.2?

Hi Paul2,

thank for your work. About

I have a new version of OG Subgroups compatible with OG 7.x-2.x that does the bare minimum of what I need it to do. I'll see if I can post a patch for it shortly.

Have you posted on og_subgroup ?

thanks!

Hi Ale.bcn,

Sorry no, it's very barebones what I've created, and now I've been shifted away from the project I originally wrote it for and have not been maintaining/improving it. I don't know what's changed in OG since I wrote that, but it might be incompatible now. I think it really should be rebuilt by someone with some background in OG development.

Hi all,

I'm having an strange error when patching the latest HEAD, fatal: corrupt patch at line 585. Does someone know how to fix this?

Thank you,

Julian Mancera

any updates??

This module is perfect but still no interface in D7

Updating priority and version. This is a 4 year old feature request, so it doesn't seem to be broadly accepted as "critical". I think if it is going to be included in 7.x it would be in 7.x-2.x.