id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
26737	models.EmailField(unique=True) in custom AbstractBaseUser throws auth.E003 during makemigrations	Matthew Miller	nobody	"I'm trying to implement a custom AbstractBaseUser to replace the default User class. For the most part I'm following the implementation detailed [https://docs.djangoproject.com/en/1.9/topics/auth/customizing/#specifying-a-custom-user-model here], with some additional fields and nothing for '''REQUIRED_FIELDS''':

{{{
class Account(AbstractBaseUser):
    email = models.EmailField(unique=True, db_index=True)

    # ...snip...

    USERNAME_FIELD = 'email'
}}}

Unfortunately when I run '''manage.py makemigrations''' I see the following error:

{{{
pbapi.Account: (auth.E003) 'Account.email' must be unique because it is named as the 'USERNAME_FIELD'.
}}}

I can suppress this error with the following:

{{{
SILENCED_SYSTEM_CHECKS = ['auth.E003']
}}}

This allows makemigrations to proceed, but I get the following output for the '''email''' field:

{{{
class Migration(migrations.Migration):

    initial = True

    dependencies = [
    ]

    operations = [
        migrations.CreateModel(
            name='Account',
            fields=[
                # ...snip...
                ('email', models.EmailField(max_length=254)),
}}}

When I modify the above migration output by hand to include unique=True:


{{{
 fields=[
    # ...snip...
    ('email', models.EmailField(max_length=254, unique=True)),
}}}

The next time I run makemigrations Django creates a migration that removes that constraint:

{{{
operations = [
    migrations.AlterField(
        model_name='account',
        name='email',
        field=models.EmailField(max_length=254),
    ),
]
}}}

I'm not really sure what the culprit is. I've used this exact custom class before in earlier versions of Django without issue (the latest Django I can remember trying this in was 1.8), but for some reason Django 1.9 hates this class. Am I doing something wrong?"	Bug	closed	Core (Management commands)	1.9	Normal	invalid			Unreviewed	0	0	0	0	0	0