AbstractUserSocialAuth and user field related_name

[esistgut]

I am getting a problem with the user field of the AbstractUserSocialAuth: if I try to create an alternative UserSocialAuth inheriting AbstractUserSocialAuth the related_name of the user fields will clash because both will inherit the related_name from AbstractUserSocialAuth:

accounts.CustomUserSocialAuth.user: (fields.E304) Reverse accessor for 'CustomUserSocialAuth.user' clashes with reverse accessor for 'UserSocialAuth.user'.
        HINT: Add or change a related_name argument to the definition for 'CustomUserSocialAuth.user' or 'UserSocialAuth.user'.
accounts.CustomUserSocialAuth.user: (fields.E305) Reverse query name for 'CustomUserSocialAuth.user' clashes with reverse query name for 'UserSocialAuth.user'.
        HINT: Add or change a related_name argument to the definition for 'CustomUserSocialAuth.user' or 'UserSocialAuth.user'.
default.UserSocialAuth.user: (fields.E304) Reverse accessor for 'UserSocialAuth.user' clashes with reverse accessor for 'CustomUserSocialAuth.user'.
        HINT: Add or change a related_name argument to the definition for 'UserSocialAuth.user' or 'CustomUserSocialAuth.user'.
default.UserSocialAuth.user: (fields.E305) Reverse query name for 'UserSocialAuth.user' clashes with reverse query name for 'CustomUserSocialAuth.user'.
        HINT: Add or change a related_name argument to the definition for 'UserSocialAuth.user' or 'CustomUserSocialAuth.user'.

What is the expected way to override this class? As per Django's documentation the related_name should not be hardcoded in an abstract class, maybe I'm missing something, can you help?

[esistgut]

Another question regarding https://github.com/omab/python-social-auth/blob/master/social/apps/django_app/default/models.py#L50

Why is the child class hardcoded in the parent abstract class?
Shouldn't this be:

except cls.DoesNotExist:

Like it is in the mixin which is the base for AbstractUserSocialAuth?

[omab]

I've created python-social-auth/social-app-django#7 to track the needed work to fix this (second issue, cls.DoesNotExists is already fixed).

[omab]

The override should also override the user field and the corresponding related name to avoid the clash, I've removed the usage of .social_auth related field from the examples and the lib since it should't depend on such property due to overridable nature of it, Storage.user.get_social_auth_for_user(...) can be used for such means too, where Storage is the custom storage solution that overrides the built-in one.

[1nF0rmed]

Is there an alternative approach that is a bit more production-friendly?