This is code from user_service.inc, line 162:
// Any logged in user is by default authenticated,
// and leaving this role set in the user's roles array
// causes big problems because of a FAPI hack that controls
// this checkbox on the user create and edit form (and thus
// causes problems with drupal_execute()). Therefore we just
// force it to 0 here.
if (isset($account['roles'][2])) {
$account['roles'][2] = 0;
}
Problem is, I'm using this and getting the following watchdog error when I try to alter an 'authenticated user' array and save it back in to the database:
Illegal choice 0 in Roles element.
So clearly that "fix" breaks things in other cases. It needs a re-think.
For now, unsetting $user['roles'][2] in the client code just prior to calling user.save has the desired effect and bypasses this bug.
Comments
Comment #1
skyredwangCould you explain what are you doing here?
Comment #2
greg.harveySure, basically load a user, change their username and save them again via services. The actual test code looks like this (sorry, this is quite long, but well commented and you can skip most of it - just want you to have the full picture):
Without the line commented "// unset the authenticated user role due to known issue: http://drupal.org/node/827858" then I get
Illegal choice 0 in Roles element.as a response from the user.save method. With that line, everything works as expected, the altered user object is saved back to Drupal.Comment #3
greg.harveyChanging status, more information provided. =)
Comment #4
skyredwangthis should fix the problem; then you can get rid off your
unsetline.Comment #6
skyredwangcorrected the path
Comment #7
bonvga commented#6: services-827858.patch queued for re-testing.
Comment #8
voxpelli commentedJust a thought - in saving shouldn't roles be an array of role id:s? Considering it's sent into a form field of type "checkboxes" with a couple of options with key role id and value role name?
Comment #9
marcingy commentedThis code is still present in 3.x so bumoing to there
Comment #10
kylebrowning commentedUnfortunately in 2.x you are going to need to continue to unset the role value, i havnt found a work around for 2.x. (and im not really focusing my time on 2.x)
If youd like to submit a patch
In 3.x however this code should not exist.
I have tested it in 6.x-3.x and half the issue is that you should never be setting the authenticated role.
The same exists for 7.x-3.x.
If you wish to set a role, the data looks like this
$account[roles][RID]=[RID]
RID is always equal to the Role id.
Ive removed this code in 6.x-3.x and 7.x-3.x, but im very reluctant to remove it from 2.x.
At any rate, what I have found is that you should never be setting the authenticated role to a user, is status what you're looking for?