add ACCOUNT_USER_MODEL_EMAIL_FIELD_METHOD to handle related model fields.

[acuD1]

Hi,

I wonder if you are interessting for this PR: acuD1#1.

Handle the case where the email field is not directly on the user model, but instead on a related model. This is the case when using a custom user model with a separate email model.

The default is to use the email field directly on the user model specified by USER_MODEL_EMAIL_FIELD.

For example:

def get_user_email(self, email):
    # Custom logic to verify the email
    return self.user_email.get(email=email).email

This would be used in conjunction with:

ACCOUNT_USER_MODEL_EMAIL_FIELD = "user_email__email"
ACCOUNT_USER_MODEL_EMAIL_FIELD_METHOD = "get_user_email"

Assuming the user model has a related model called user_email with a field called email.

class UserEmail(models.Model):
    user = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE)
    email = models.EmailField(unique=True)

    class Meta:
        abstract = True

class CustomUser(AbstractUser):
    email = models.EmailField(unique=True)

    def get_user_email(self, email):
        return self.user_email.get(email=email).email

[pennersr]

I am not sure I fully understand the purpose here. There is already a related model that stores the email -- allauth.account.models.EmailAdddress. Isn't your UserEmail almost the same as that?

[acuD1]

Hi again,

Yes, those models are the same. However, in scenarios like my codebase, which already utilizes a UserEmail model, the ACCOUNT_USER_MODEL_EMAIL_FIELD is not enough. This PR can make django-allauthcompletely agnostic of existing AbstractUser configurations.

For example, considering the AbstractUser model described above:

The SQL query from line 490 to 491:

q_dict = {app_settings.USER_MODEL_EMAIL_FIELD + "__iexact": email}
user_qs = User.objects.filter(**q_dict)

The ACCOUNT_USER_MODEL_EMAIL_FIELD is enough to work on any UserEmail models linked to CustomUser.

However, the line 493:

 user_email = getattr(user, app_settings.USER_MODEL_EMAIL_FIELD)

Cannot work, as the gettatr function doesn't work with query syntax: user_email__email.

The proposed solution addresses this scenario by allowing getattr to invoke a method on the model with the setting ACCOUNT_USER_MODEL_EMAIL_FIELD_METHOD.

Perhaps I am mistaken, but after reviewing the codebase, it's the only viable solution I found for integrating complex UserModel configuration without hindering the integration with django-allauth.

[pennersr]

That line you are referring to:

user_email = getattr(user, app_settings.USER_MODEL_EMAIL_FIELD)

That is preceded by a if app_settings.USER_MODEL_EMAIL_FIELD. So, if your user model does not have an email field just configure this setting to None. Note that allauth does not require that this field is present, so it is already agnostic of "existing AbstractUser configurations" as you put it.

I don't quite understand the purpose of your UserEmail model. Why is that needed given that there is already allauth.account.models.EmailAddress? Note that you cannot get rid of the latter as you do need to keep track of state (e.g. verified or not). And then, given that the EmailAddress model is already there (and there to stay), why duplicatate part of that data into UserEmail? I would prefer a single source of truth and have just one place to store email addresses.

[acuD1]

We have a well-established User model in our Django application that includes a UserEmail field with its own configurations, such as support for multiple emails, primary emails, etc.

We integrated django-allauth primarily to manage external providers. However, we are not yet fully utilizing django-allauth, so we cannot completely abandon our existing implementation.

I propose a convenient method to support this migration and suggest using django-allauth merely as an overlay for our use case.

Do you think it's a security issue to do it this way ?

[acuD1]

We're planning to use EmailAddress and see how it goes. So no PR needed. Thanks for your time nonetheless.