default state used to be Active; now it's Pending

I'm seeing the same behavior...

-mike

Same here. Is there a place where the default membership state can be set to "Active"?

It might be related to this change.

1. Is the group the user is added to defined as skip approval?
2. When adding the user via OG's "add people" page, does it work properly?

1. Is the group the user is added to defined as skip approval?

Where is this setting? I don't see it at admin/config/group/settings or admin/config/group/permissions/node/group. And Googling various combinations of things didn't get me any closer to finding where this could be hiding from me in OG.

2. When adding the user via OG's "add people" page, does it work properly?

Yes. Just tested both ways. Added a user via Add People and the user was Active immediately. Removed user Visited the user's page, added to the group, went back to the group and the person was there as Pending.

Where is this setting?

This is the permissions for the group level. Depends on how you defined it, but most probably under admin/config/group/permissions

Ah-ha. Thanks.

For others - to allow users to be added to a group from their user profile page (by a site admin) AND for their membership to be set to Active and not Pending, you still need the group's permissions to be set to "no approval required."

In the permissions matrix under admin/config/group/permissions, look for:

Organic Groups UI
Subscribe to group (no approval required)
Allow non-members to join a group without an approval from group administrators.

Check the box for "non-member" for this row.

If you only want members to be added by site admins, though, and not by users from their own user profile pages, you will need to check other permissions to confirm that the user doesn't see the group list on his/her profile page.

using the solution from above, described in full in #7, any site member can just join any group via group/node/*/subscribe
A serious security risk on our sites if we enable that, as anyone can create an account.

the previous behavior was that when an admin user adds a user to a group (from that users profile), it was approved right away. I see no use in placing the group member in a pending membership when the acting user is a group admin.

What changed and how can we revert to the old behavior?
For us, this regression is a major issue.

I tested what is described in #8 because we also allow users to create accounts. Drupal user accounts must be approved by a site admin, though, so that might be a little different.

Here's what I did: I pretended I was a new user and created an account. As a site admin, I went in and approved the account but didn't add the user to any groups. I logged in as the new user and tried to subscribe to an account at group/node/*/subscribe. The "join" option was there and I clicked successfully. However, when I went to the group's page, it was inaccessible (Access Denied), even after logging in and out. So, the group subscription was not successful from the new user's standpoint. As a site admin, I looked at list of group members and there was the new user but still Pending.

So, it seems the fix in #7 is working for us. However, this is odd given that we have the "subscribe to group (no approval required) permission checked now and it shouldn't work this way! Something is screwy with OG permissions.

Same issue here as described above. I hadn't even noticed there was a Pending state before this error.

bump.

As this is a regression / change from previous versions, this might be better categorized as a bug report?

Meanwhile, we fixed this using a simple rule to auto approve, works fine for our case and we don't have to open up any more permissions as described in #7.
However, be careful using this on a site where anyone can apply for group membership, as those memberships would be approved right away.

{ "og_og_auto_approve_member_subscribe" : {
    "LABEL" : "OG auto approve member subscribe",
    "PLUGIN" : "reaction rule",
    "OWNER" : "rules",
    "TAGS" : [ "coworks" ],
    "REQUIRES" : [ "rules", "og" ],
    "ON" : { "og_user_insert" : [] },
    "IF" : [
      { "data_is" : { "data" : [ "og-membership:state" ], "value" : "2" } },
      { "entity_is_of_type" : { "entity" : [ "og-membership:group" ], "type" : "node" } }
    ],
    "DO" : [ { "data_set" : { "data" : [ "og-membership:state" ], "value" : "1" } } ]
  }
}

We've applied a fix in https://github.com/Gizra/og/pull/124 but it hasn't been merged as yet.

I can confirm the problem still exists and I think it's really problematic for many sites.
So I'd suggest to introduce a new setting where to set the default state after setting a users group. This would be the most flexible solution I think.

I tested the code from Gizra's github and left a comment there as well that this worked for me.
https://github.com/Gizra/og/pull/124

I tested this code on OG 7.2.9 where I had the same issue as described in this issue:

https://www.drupal.org/node/2744405

I found the code work as expected and now an administrator can add a user to a group and have it be active instead of pending. This was the behavior that was previously in place.

I created a patch against eh 7.x-2.x dev version that works for me on the present 7.x-2.9 version as well in the hopes it helps someone else. All the thanks to chris_h for the code.

Thank you very much. The patch works good for me. Further feedback for RTBC?

@mmcintosh I suggest removing the old line of code which is commented out in your patch. Other than that I have also tested this and it really is RTBC.

Rerolled #17 to remove the commented code.

Thanks. The tests seem to fail. Would be great also to have a simpleTest to prevent regression.

Actually, sorry - closed in favor of the GitHub PR

https://github.com/Gizra/og/pull/124#issuecomment-254349342

I don't see this commit in og 7.x-2.10. Has it been fixed elsewhere now or was it just omitted?

I don't see this commit in og 7.x-2.10 on drupal.org. Has it been fixed elsewhere now or was it just omitted?

I ran into the same question myself today while applying updates. This diff of the og-7.x-2.9 file in question against the 7.x-2.10 version seems to indicate that this commit/patch is no longer needed because the code affected by the patch is completely gone:

diff --git b/sites/all/modules/og/plugins/entityreference/behavior/OgBehaviorHandler.class.php a/sites/all/modules/og/plugins/entityreference/behavior/OgBehaviorHandler.class.php
index dc7373f7..d17a8e26 100644
--- b/sites/all/modules/og/plugins/entityreference/behavior/OgBehaviorHandler.class.php
+++ a/sites/all/modules/og/plugins/entityreference/behavior/OgBehaviorHandler.class.php
@@ -122,11 +122,7 @@ class OgBehaviorHandler extends EntityReference_BehaviorHandler_Abstract {
     foreach ($items as $item) {
       $gid = $item['target_id'];
 
-      // Must provide correct state in the event that approval is required.
-      if (empty($item['state']) && $entity_type == 'user' && !og_user_access($group_type, $gid, 'subscribe without approval', $entity) && !og_user_access($group_type, $gid, 'administer group')) {
-        $item['state'] = OG_STATE_PENDING;
-      }
-      elseif (empty($item['state']) || !in_array($gid, $diff['insert'])) {
+      if (empty($item['state']) || !in_array($gid, $diff['insert'])) {
         // State isn't provided, or not an "insert" operation.
         continue;
       }

(cross-posting to https://github.com/Gizra/og/pull/124#issuecomment-404972537)

@jackalope: I think you're right. It's been a month now and I'm seeing no problems.