ldap authorization: og 1.x not working (organic groups)

I can't replicate this. Can you do the following:
0) Try the 7.x-1.0-dev version. I don't think any recent changes would affect this, but it has additional debugging logging messages.
1). Pick the user your are going to test with and figure out their user id (uid)
2) make a note of the records in og_memberships and og_user_roles and delete any with that uid.
3) enable ldap_help module and check the detailed logging checkbox at admin/config/people/ldap/settings
4) goto admin/reports/dblog and clear the old log messages (unless you need them for something)
5) log the user in to test the authorization creations

6) check the 'og_memberships' and 'og_user_roles' tables and see if any records were created for that uid.
7) goto admin/reports/dblog. There should be a log record that looks like:

TYPE	ldap_authorization
DATE	Saturday, March 24, 2012 - 22:39
USER	jbarclay
LOCATION	
REFERRER	
MESSAGE	jbarclay : user_authorizations_set results for og_group:
1. Initial existing authorizations:
1. Filtered Authorizations: 1-3
2. After filtering off previously granted authorizations: 1-3
3. All available existing authorization ids: 1-1, 1-2, 1-3, 1-4, 3-1, 3-2, 3-3, 3-4
4. authorization ids that need to be created: none
5. consumer containers existing after create call (or non-call if og): 1-1, 1-2, 1-3, 1-4, 3-1, 3-2, 3-3, 3-4
6. Grants passed to authorizationGrant(): 1-3
7. revokes passed to authorizationRevoke(): none

Post that here. It will help figure out why its not attempting to create the membership.

do you see any watchdog entries after that? the ones that are generated in LdapAuthorizationConsumerOG.class.php in the function grantSingleAuthorization()?

Do those 2 database tables look correct for that user id?

I fixed a bug in the test form and the ldap_authorization_get_consumers() function. I don't think this has anything to do with the og bug, but it may have created some interference between the 2 authorization approaches (roles and og groups) if both were enabled. I'm still working through some other implications from this, but hope to have a commit Monday or sooner.

What version of OG are you running?

I'm developing and testing against the 7.x-1.3 branch. If anyone is using the 7.x-2.0-dev branch or 7.x-1.2, 7.x-1.1, I would love to know if they are succeeding or failing so I can give a warning that the the 7.x-1.3 branch is required.

I was having the exact same problem. The og_membership entry seems to be the table that matters for basic membership. An entry in that table indicates "member". If you grant another OG role like "administrator member" to a user then an entry appears in og_users_roles.

After visually tracing the code I could not see how an og_membership row would be created. After reviewing the og.module code and the relationships between the OG functions I decided to change the following line of the grantSingleAuthorization function in LdapAuthorizationConsumerOG.class.php.

                // CASE 5:  grant role

                // og_role_grant($gid, $user->uid, $rid);
                og_group($gid);

IANAOGE: I am not an OG expert.

It works for my cases where all I'm trying to grant is group membership. The og_group function also accepts and array parameter for more options.

Thanks for tracing through the code. og_group($gid) won't work for most use cases, since it assumes the current logged in user. But isolating the problem to the og_role_grant() function is very helpful.

@mike64. With this change, does the mapping work well for you? Are you using it with LDAP Authorization Drupal Roles also? I'm not getting a lot of feedback on who is succeeding and failing with ldap og. When you are tracing, what are the values of $gid, $user->uid, and $rid when og_role_grant() is called?

I added another debug line in LdapAuthorizationConsumerOG.class.php that watchdogs the $gid, $uid, and $rid being passed to og_role_grant(). To help further debug this, use 7.x-1.0-dev, enable ldap help module, enable detailed logging at admin/config/people/ldap/settings, login with user to be granted groups, and check watchdog logs.

Some other thoughts:
- make sure you have the server and configuration enabled at the top of admin/config/people/ldap/authorization/edit/og_group
- the simpletests work fine and test the call to og_role_grant() as an api call (in testBasicFunctionsAndApi()) as well as test roles granted on logon (in testAuthorizationsOnLogon()), so any help getting to the bottom of this pesky bug is greatly appreciated.

added some keyowrds since "og" isn't searchable

I seem to be having the same problem. The watchdog entries seem to be fine when I log in but membership to the group is not granted. Trying to access a private group says access denied in the log. Has this problem been solved? im using ldap 7.x-1.x-dev with OG 7.x-1.3....Any advice would be appreciated.

This has not been solved. Comment #13 may be a viable workaround if you are only using the default membership of organic groups. Looking for feedback on #14, but will follow up on recreating and fixing regardless when I get a chance.

I committed some changes to 7.x-1.x-dev (see #1559388: LDAP Authorization Organic Groups: OG 7.x-2.x Support). Most of them are related to og 7.x-2.x. But the code:

			$values = array(
				'entity type' => 'user',
				'entity' => $user,
				'state' => OG_STATE_ACTIVE,
				'membership type' => OG_MEMBERSHIP_TYPE_DEFAULT,
			);
			$user_entity = og_group($gid, $values);
			og_role_grant($gid, $user->uid, $rid);

basically does what comment #13 does, but supports user's beside the currently logged in user and supports roles. Please test.

I committed a number of other ldap og fixes to 7.x-1.x-dev. So this issue and some of the patches in it are no longer relevant and I'm closing this. One issue was not reloading the user object after the og fields were populated, thus writing back over them.

Any testing of 7.x-1.x-dev against og 7. x-1.4 would be greatly apreciated.