Allauth 0.61.1 is defeating user pre_save signals and instance updates during primary email change

[marty0678]

I haven't tracked down why exactly yet, but something simple like:

@receiver(pre_save, sender=settings.AUTH_USER_MODEL)
def set_username_to_email(sender, instance, **kwargs):
    """Sets the username to be the same as the email."""

    # Unless they don't have an email
    instance.username = instance.email if instance.email != "" else instance.username

Has broken in Allauth 0.61.1. I upgraded from 0.51.0 and can confirm this was working as intended (where the username was being updated correctly and then saved back to the DB) in 0.51.0.

What is stumping me right now, is debugging through allauth's code, the instance object does correctly get the proper username field updated, right up until the response back to the frontend, except it's never then saved back to the DB like it was before.

Update 1: If I save the model manually after or from the admin (outside AllAuth's request flow), it updates as expected. I believe this is only an issue when the user is updating their primary email from the template/view, something in that flow is preventing the instance from being updated it seems.

Update 2: Doesn't seem specific to the pre_save, if I move the logic into the model's save method, it does the same thing.

I'm still working through it, but has anyone encountered this?

[pennersr]

I don't have any guidance on the (pre_)save issue, though, I do find it a bit tricky to hook into that signal like that, as it gets triggered in many different scenario's, whereas you likely want to intervene only at account creation time? So I would suggest to hookup to one of the adapter methods instead, for example:

https://github.com/pennersr/django-allauth/blob/main/allauth/account/adapter.py#L277

Additionally, I am wondering why you would want to do this at all? Semantically, the username field is different from email, why try and sync these? When you go this route, changing the email affects the username, which may be unexpected.

[marty0678]

Hey, thanks for the response and everything you do for this repo!

My goal is to basically 'defeat' the built-in username as username isn't really that used much anymore on most sites. So the way I've been doing it / presenting to the user is your primary email is your login method and if you change your primary email, your login will change with it. That way a user could swap out their email completely on their account, and not have to either manually update their username after, or still be forced to log in with their previous email when it wasn't used on the account.

I could have created a custom user model that just doesn't have a username field, but it was a little too late for that when I did this work, so my solution was to just override the username with whatever their email was, which worked great when the primary email was updated.

As such, I want this logic to run whenever the user is saved, not just when it was created, specifically for Allauth's changing the primary email.

What my planned workaround for now is, is to just queue up a celery job that syncs the username to the email there instead, as that seems to get around whatever is blocking the instance from being updated when Allauth does it.