There are some related issues regarding this setting, but I do not see this exact problem described anywhere.

Problem

When the "Alter email field on user edit form:" setting in "LDAP UI Options" is set to "Remove email field from form" then any changes made to the email address on the LDAP server will not sync to the user account even if mapped in ldapdata and in fact any call to user_save will be unable to change the user's email address.

My expectation is that this setting should prevent the user from changing his email field, but not prevent the field from being changed by core or other modules like ldapdata.

Details

The ldapauth module's implementation of hook_user has an 'update' op with the following code:

if (LDAPAUTH_ALTER_EMAIL_FIELD == LDAPAUTH_EMAIL_FIELD_REMOVE)
  unset($edit['mail']);


The core user_save function invokes the hook_user update op right away, and so the above code effectively prevents anyone from changing the mail field while the setting is enabled.

The ldapdata module, when syncing fields calls user_save at the very end of _ldapdata_user_load as well, preventing the mail field from syncing via ldapdata.

Solutions...

I don't think this could be by design since part of the point of preventing a user from changing his email address could be because you use ldapdata with read-only mapping and expect to pull in updated email addresses from the LDAP server.

There must be a way to prevent the user from editing his email field without unsetting the mail field in hook_user updates.

Comments

cgmonroe’s picture

cgmonroe commented
Version: 6.x-1.0-beta2 » 6.x-1.x-dev

I've verified that this happens in the dev version...

IMHO, the solution to this is to change the op from 'update' to 'validate'... then the mail information will only be dropped when the edit form is validated... and where form data transformations should happen. I think that the test should also be for both options here... e.g. disabled and removed... since the "READONLY" attribute of an input field does not work in some browsers/can be overridden to allow changes.

I'll add this change to the next set of changes I'm working on. Should be in the dev version later this week.

cgmonroe’s picture

cgmonroe commented
Status: Active » Fixed

The dev version now has the fix for this... (or will when it re-generates).

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

dtecson’s picture

dtecson commented
Status: Closed (fixed) » Active

Unsetting that field affects non-LDAP user account creations. When the create account form validates, it unsets the field. Maybe adding a check to see if it a 'create account' submission first?

cgmonroe’s picture

cgmonroe commented

Good catch. The conditional is missing the test if the user is an LDAP authenticated user or not. The following code change in the ldapauth_user function should correct the problem:

    case 'validate':
      if (isset($account->ldap_authentified) && LDAPAUTH_ALTER_EMAIL_FIELD == LDAPAUTH_EMAIL_FIELD_REMOVE || LDAPAUTH_ALTER_EMAIL_FIELD == LDAPAUTH_EMAIL_FIELD_DISABLE ) {
        unset($edit['mail']);
      }

I'll check this in to the dev version in a few days (swamped @work right not...sigh clients can't live with them... can't eat without them). :)

cgmonroe’s picture

cgmonroe commented
Status: Active » Fixed

Change committed to -dev.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

alieffring’s picture

alieffring commented
Status: Closed (fixed) » Needs work

The fix only works if the Alter email field on user edit form setting is set to Remove email field from form. If it's Disable email field on form the conditional resolves to
FALSE && FALSE || TRUE
which thanks to order of operations ends up resolving to TRUE.

The proper fix is to wrap the LDAPAUTH_ALTER_EMAIL_FIELD tests in parens, like so:

    case 'validate':
      if (isset($account->ldap_authentified) && (LDAPAUTH_ALTER_EMAIL_FIELD == LDAPAUTH_EMAIL_FIELD_REMOVE || LDAPAUTH_ALTER_EMAIL_FIELD == LDAPAUTH_EMAIL_FIELD_DISABLE )) {
        unset($edit['mail']);
      }
      break;