I'm really happy to see there's a user_delete() function now instead of all the code being in user_edit() but I'm concerned that the drupal_set_message() call has been moved in there. This makes user_delete() much less useful as an API call. I would suggest that the drupal_set_message() call be moved back out into user_edit() since that function is dealing with the user interface, whereas user_delete() could be just dealing with the deletion itself.
I also wonder about the $edit parameter to user_delete(). Again, as an API call, you wouldn't have those. Do any of the hook_user() implementations even use that field? If not perhaps we could make it:
function user_delete($uid, $edit=null) {
...
}
And then user_edit() could still provide it but if we didn't have it, we wouldn't have to.
I have an ldap module customized for our institution and it needs to handle some weird recursive edge cases (don't ask) that could result in an old account getting silently deleted when a user who has had their email address changed logs in. Or at least, I'd like it to get *silently* deleted. At the moment we're using 4.7 so I have to copy all the DELETE sql queries into my function but I'm looking forward to turning that into a call to user_delete() in 5.0 if I can make it useable to other modules.
Thanks.
Comments
Comment #1
jfitzell commentedobviously it would be nice to fix these before 5.0 is released and external code is written that depends on the current interface for user_delete()
Comment #2
ricabrantes commentedany news about this?
Comment #3
marcingy commentedComment #4
gpk commentedFixed in 6.0 or earlier.
@ricabrantes: it would be even more helpful if you could investigate the issue rather than just posting "any news" ... Thanks.
Comment #5
gpk commentedto be precise ;-)