Page listing social connections should use email addresses or usernames, instead of names

[Flimm]

Take the page at the URL /accounts/3rdparty/ (URL name socialaccount_connections configured to allauth.social.views.connections). If you load that page, it will list all the social connections of the current account, like this:

• ( ) John Smith Google
• ( ) John Smith Facebook
• ( ) John Smith Google

It lists each account by displaying the name of the account, followed by the provider name. Unfortunately, the name of the account is often the first name and last name of the person associated with that account. A user may have multiple accounts with Google under the name "John Smith", and may not be able to discern which one is being referred to here. Even if the user has not connected all their Google accounts that have the name "John Smith", they still cannot tell which one of their Google accounts with the name "John Smith" is being referred to here. To put it succinctly, names are not unique identifiers for Google.

Instead, I suggest using an identifier that is unique to that provider, for example, an email address or a username, like this:

• ( ) Google account johnsmith1@gmail.com
• ( ) Facebook account johnsmithy
• ( ) Google account john.smith.abc@gmail.com

I propose that the method get_identifier be added to the ProviderAccount class:

class ProviderAccount(object):
    def get_identifier(self):
        """
        Returns a string representing an identifier that is uniquely identifies
        this account among the provider's accounts, preferably one that is
        meaningful to human beings. This is usually a username or an email address.
        """
        return None

I also propose modify the to_str method on that class so that it uses the get_identifier method, falling back to the previously implemented return value if get_identifier does not return a truthy value.

    def to_str(self):
        return self.get_identifier() or self.get_brand()["name"]

Then providers can override the get_identifier method to return an email address or username, and to_str will continue to work even for providers that haven't implemented the get_identifier method yet.

[pennersr]

Thoughts:

• "representing an identifier that is uniquely identifies this account" -- this would only be usable by humans, as an email address and/or username could be modifiable over at the provider. Hence, this identifier is not to be used for other purposes...
• Given that it is just for display purposes, do we really need a new method, or could we just alter the to_str() method?
• You likely put return None there so that there is some default, as changing this for all providers is quite a job. But, that leaves if with new method that sometimes gives a result, sometimes not... so that also points to not adding a new method and just altering to_str().

[Flimm]

That works for me. I'm happy with modifying to_str instead of adding a new method get_identifier. Let me know if you would welcome a pull request with this change.

[pennersr]

Yes, the purpose of that to_str is to return something human identifiable/recognizable, so feel free to improve it -- as long as there is a fallback to the old behavior in case the new field you are aiming for is not there.

[Flimm]

The fix has now been committed and is ready for the next release. Thank you so much for your collaboration, @pennersr .