Invisible menu tabs

pcorbett

Were you able to make a patch ? We can roll that into the 5.x-1.4/HEAD

kreaper

ldapauth module now has the code to retrieve the email address and set it accordingly, if available.
This is available in 5.x.1.3 and in HEAD

  
    if (key_exists(($ldapauth_ldap->getOption('mail_attr') ? $ldapauth_ldap->getOption('mail_attr') : LDAP_DEFAULT_MAIL_ATTRIBUTE), $ldap_user)) {
      $mail = $ldap_user[$ldapauth_ldap->getOption('mail_attr')][0];
    } else {
      $mail = "";
    }
  

I'm at 5.x-1.3 and I still don't get email information when a new account is created through LDAP/Active Directory. I've tried "mail", "smtp", and "SMTP" as values for the "email attribute" setting. The rest of my LDAP authentication is working just fine. So if the patch is in 5.x-1.3, I don't think the problem is solved yet... or possibly I have the wrong email attribute setting. Any suggestions about values for this field would be very welcome.

I've discovered that the LDAP integration module is actually erasing email addresses stored in the user account if it can't get a value from the LDAP/AD server. I think this is a pretty bad failure mode. The old version at least left existing values alone. Now my users suddenly don't get notices from the system any more, because their address has been replaced by null.

I'd like to suggest that the system check for a null return from the email address call and if null, don't change the current email value for the user.

pcorbett - Did you figure out the problem? What type of server are you authenticating against? What is currently in the mail attribute field? What is the attribute name on your ldap server? BTW none of the ldap_integration settings are supposed to defeat core's email requirement, only make it easier to populate it from LDAP and hide it from the drupal user.

emdalton, can you provide a bit more information? I have been unable to reproduce the email address getting overwritten. Are you using AD or LDAP? What is the mail attribute name on your ldap server? You need to know that - neither we nor the module can figure that out for you:

I've tried "mail", "smtp", and "SMTP" as values

On the ldap auth configuration page in drupal, set the mail attribute to: userprincipalname

I just found a bug where, at least with an Open LDAP server, the attribute names from the server are all lowercased. The ldapauth module checks for the existence of the attribute in the ldap record before reading it - UserPrincipalName <> userprincipalname so it doesn't even try to read the mail attribute... It shouldn't matter that the cases don't match from the LDAP server's perspective - I'm 99% sure AD doesn't care about case and have found OpenLDAP doesn't appear to care either.

I'm not sure how extensive of a problem it is, but it's on my list. Let me know if changing the case helps.

scafmac, we're using AD and we don't have email addresses stored in the authentication system at all, so the module can't retrieve them. I just need to make sure it doesn't wipe out addresses that get added manually to Drupal.

pcorbet - I've noticed #4 and have assumed it is a garland bug since in every other theme I've tried, it works fine. But I'm happy to take a closer look at it, but it would be best if you open it as its own bug.

I have a fix for the case problem, I just hadn't had a chance to confirm it was a problem with AD as well - you've done that so I'll work on the fix for the next version.

emdalton - let me see if I've got it:

• No email addresses in AD.
• Nothing for mail attribute on the ldapauth admin page
• No problem on first login, but on subsequent login, any email address for the drupal record is deleted.

Does that cover it?

Yes, that covers what we experienced with 5.x-1.3. We backported to 5.x-1.2 until this can be resolved.

I'm not sure why the issue title was changed. I still hope "Disable requiring e-mail on edit User" gets addressed someday.

Closing 5.x issues to clean out issue queue.