Having re-read this and thought about it a bit more, I think what you 
need to do is to put in preference hooks for email address and user 
name. The other solution I'd accept would be to modify the edit form 
to include _all_ extra fields. But treating just email and name as 
extra fields like this doesn't make sense to me.

Ok let me explain more clearly.

I'm speaking about information passed to the auth backend which is an 
ldap backend in my case. I also use the _horde_hook_authldap() hook to 
format my ldap entry properly.



The problem I had is my hook was never called on an update if I only 
change the user name or user email for example. The clue is in the 
user.php code.



If you look at the present code  :



if ($auth->hasCapability('update')) {

         $user_pass_1 = Util::getPost('user_pass_1');

         $user_pass_2 = Util::getPost('user_pass_2');



         if (empty($user_name_1)) {

             $notification->push(_("You must specify the username to 
update."), 'horde.error');

         } elseif (empty($user_pass_1) || empty($user_pass_2)) {

             // Don't update, but don't complain.

         } elseif ($user_pass_1 != $user_pass_2) {

             $notification->push(_("Passwords must match."), 'horde.error');

         } else {

             $result = $auth->updateUser($user_name_1,

                                         $user_name_2,

                                         array('password' => $user_pass_1));

         }

     }



you see :



1.  the only passed information to the auth backend is :

  - $user_name1

  - $user_name2

  - an array with only the password



2. $auth->updateUser() will be called ONLY if these is a valid 
password change in the UI. Look at the serie of if/elseif/elseif/else 
to check.



So I changed that to

1.  keep the password fields validation check

2. allow people to change other fields but not the password

3. insert new fields to the $creds array passed to the auth backend : 
user_fullname and user_email that were missing previously



The do ... while(false)  is only a container that allows code to 
escape this block in case of error with a simple break  without having 
to deal with multiple   if/then/else  (see this block as a try  catch   
block)



I did that because there are code to execute unconditionnaly before 
leaving the 'update' case :



  $vars->remove('user_name');     presently.



I hope I have been better understood.

Your addition of the do/while block obscures what else is changing 
here, and I don't see the point of it. Right now, the code _does_ 
update name/email fields if either the password update succeeds, or if 
a new password isn't entered. So I don't see the bug. Can you please 
elaborate, and perhaps post a smaller diff? Thanks.

patch against [ Horde ] / horde / admin / user.php  version 1.47.10.7 to :



currently updating a user is only possible if password is changed, and 
is the only changed field passed to the backend with eventually a 
current short name change too.

But the web UI interface also shows user_fullname and user_email 
fields too, but this is ignored by the current code.



- FIX: when updating credentials 'user_fullname' and 'user_email'   
fields were not passed to backend

- refactor update possibilities :  allow updating even if admin does 
not change passwords ( ie: name or fullname or email only)