Show child groups when creating content when og_group_ref/og entityref field is using og group selector

Yes, this definitely needs to be added. In my own dev site I'm using a form alter with a extend class of entityreference selector. Need to think about the best way to do this though...

I've submitted a patch here that changes a lot of the current code, and also removes the need for this patch. If you have time can you please review the patch and give feedback? Thanks!

Norman

Until I can spend more time testing and reviewing #1956426: Content Inheritance I am going to commit this simple patch. It's something we have been using in Open Atrium 2 for quite a while and is a step in the right direction. I'm not a fan of completely changing the inheritance architecture. Trying to make minimal changes so we can get an Alpha release of this module. Then we can work on the inheritance in more detail.

Committed #5 to 21f7a46

Actually, reverted this commit in db7516c. This is no longer needed in the latest OG -dev. You can simply write your own entityreference selection class (as shown in the og_examples module).

Sorry for reopening this, but I think an entityreference selection class should be added to the module (or at least an example).
Right now I think this is the last step this module is missing. Having an extra module just for a proper entityreference selection class seems wrong?

Could you maybe add an example class here that works with subgroups, I'm not really sure where to start (I will try playing around with this, but if it doesn't help me it will probably help someone else?).

I've added a first attempt to fix this. It's basically a copy of the og entityreference plugin, with the small change that we use og_subgroup_user_groups_load(NULL, FALSE) to get the data.
Please let me know if this works and if it is a good idea to add this to the module!

I fixed a small issue and some copy paste typo's. Attached is a new patch.

There is a related issue in OG which causes some issues with custom entityreference selection classes:
https://www.drupal.org/node/2307065

Patch from #11 works ok for us, but it's missing a global $user.

The patch in #13 works great! I have spent hours today trying to figure out why my entity reference fields were not displaying entities that a user was an inherited user of. This seems like a fundamental part of og_subgroups to me. I'd love to see this commited!!

Thx @seanB and @abautu for your work on this!

After some further testing... the field displays perfectly and as expected, inherited users see group options in a dropdown/checkbox list, etc. The user can select any of the options and save the form and it saves properly. However, if the group option has been set to a value that the given user is not a direct member of and he/she goes to change the group to anything else, an exception is thrown.

Here is my use case:
- I have a node group called class.
- I have node called student that is group content of class (student is a node, not users)
- I can change a student from one class to another as often as I want, as long as the user that I'm logged in with is a direct member of the class.
- If I change the student's class to one that the user is an inherited member of, it saves fine, BUT when I try to change the student's class again, to anything (direct member or inherited) an exception is thrown.

Not sure if this is specific to this issue or if a new issue should be created, but thought I would at least start here :)

After finding #2307065: Issue with custom selection class and field widget in comment #12 above everything is working well from my testing. I think this would be great functionality to add to og_subgroups.

bocaj: In #17 when you said the patch is working, you probably should have moved the status back to RTBC so it didn't get lost for so long.

In any case, taking a new look at this and it looks good. It's similar to what we did in Atrium, although we had to jump through a few more hoops to handle some of our special access control rules.

Since this patch doesn't change anything for existing users and just adds a new selector plugin, I'm going ahead and committing it.

Committed to 17c3501.

Commit 17c3501 only includes the CTools plugin directory hook implementation and is missing the selector plugin file itself. Hence status is back to reviewed & tested by the community until this gets commited fully.

Sigh, I hate it when that happens.

OK, I reverted the previous commit and did a new commit f289a46 with the correct files. Sorry about that!