Use a case-insensitive email field. (Requires Django 1.11.)

[adam-thomas]

@incuna/backend review please?

[coveralls]

Coverage remained the same at 100.0% when pulling 9d016c9 on email-case-insensitivity into a4506a1 on master.

[meshy]

This is cool, but does introduce a requirement on Postgres over other (lesser?) databases.

While I'm not sure it's foolproof, I've had success with the following, which I present as an alternative:

class User(...):
    ...

    def validate_unique(self, exclude=None):
        """
        Checks unique constraints on the model.

        Overridden to validate email in a case insensitive manner. Some of the
        logic has been derived from _perform_unique_checks().

        https://github.com/django/django/blob/1.9.7/django/db/models/base.py#L1014-L1030
        """
        # Validate email unless explicitly excluded.
        exclude = exclude or []
        errors = {}
        if 'email' not in exclude:
            qs = User.objects.filter(email__iexact=self.email)
            if not self._state.adding and self.pk is not None:
                qs = qs.exclude(pk=self.pk)
            if qs.exists():
                errors['email'] = self.unique_error_message(User, ('email',))
            exclude.append('email')

        try:
            super().validate_unique(exclude=exclude)
        except ValidationError as error:  # pragma: no cover
            # email is currently the only unique field, so impossible to test
            # this. Skipping from coverage (sorry)!
            errors.update(error.error_dict)

        if errors:
            raise ValidationError(errors)

[coveralls]

Coverage remained the same at 100.0% when pulling 17ba7c3 on email-case-insensitivity into a4506a1 on master.

[adam-thomas]

@meshy hmm, thanks! @incuna/backend opinions on Charlie's suggestion over my existing implementation?

[LilyFoote]

Another alternative is to add a CIEmailUserMixin alongside EmailUserMixin. This is backwards compatible and allows users to move to the new postgres shiny if they desire.

[adam-thomas]

That's a good idea.

[adam-thomas]

Actually it kind of requires doubling up on all the mixins. If it's going to be backwards compatible it's probably better to use Charlie's suggestion. Since 1.11 is LTS it's probably ok to drop the support for older versions though.

[meshy]

If it helps to muddy the waters a little, I actually prefer your version, and would use it if I could :P

[adam-thomas]

Lol. I think I prefer it as well because there's less of it (probably works more reliably) but I don't know how much this library is used on non-postgres systems.

[LilyFoote]

It probably isn't used by anyone but Incuna (and maybe ex-Incuna people). So probably everyone uses postgres.

[Minglee01]

my two cents here is a needs a changlog update

[adam-thomas]

@Minglee01 oh I was going to do that once it's 'complete', but I can do it now

[coveralls]

Coverage remained the same at 100.0% when pulling 49794d2 on email-case-insensitivity into a4506a1 on master.

[adam-thomas]

Any other comments?

[coveralls]

Coverage remained the same at 100.0% when pulling 17ba7c3 on email-case-insensitivity into a4506a1 on master.

[coveralls]

Coverage remained the same at 100.0% when pulling 17ba7c3 on email-case-insensitivity into a4506a1 on master.

[coveralls]

Coverage remained the same at 100.0% when pulling 17ba7c3 on email-case-insensitivity into a4506a1 on master.

[coveralls]

Coverage remained the same at 100.0% when pulling 17ba7c3 on email-case-insensitivity into a4506a1 on master.

[coveralls]

Coverage remained the same at 100.0% when pulling 17ba7c3 on email-case-insensitivity into a4506a1 on master.

[maxpeterson]

This seems to require superuser to create the extension

[adam-thomas]

ah, how do we enable that? Would have thought we'd always have a superuser.