Bird
Raised Fist0
Djangoframework~5 mins

Custom user model with AbstractUser in Django

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Introduction

Using a custom user model lets you add extra fields or change how users work in your Django app. AbstractUser helps you start with Django's default user features and add your own.

You want to add extra information to users, like phone number or birthdate.
You need to change the way users log in, like using email instead of username.
You want to keep Django's built-in user features but customize some parts.
You are starting a new project and want a flexible user model from the start.
Syntax
Django
from django.contrib.auth.models import AbstractUser
from django.db import models

class CustomUser(AbstractUser):
    # Add extra fields here
    phone_number = models.CharField(max_length=15, blank=True, null=True)

# In settings.py
AUTH_USER_MODEL = 'yourapp.CustomUser'

You create a new class that inherits from AbstractUser.

Then add any extra fields you want inside that class.

Examples
This example adds a birth date field to the user.
Django
from django.contrib.auth.models import AbstractUser
from django.db import models

class CustomUser(AbstractUser):
    birth_date = models.DateField(null=True, blank=True)
This example adds a bio field that can be empty.
Django
from django.contrib.auth.models import AbstractUser
from django.db import models

class CustomUser(AbstractUser):
    bio = models.TextField(blank=True)
Don't forget to set AUTH_USER_MODEL to your custom user model in settings.
Django
# settings.py
AUTH_USER_MODEL = 'accounts.CustomUser'
Sample Program

This code defines a custom user with a phone number field. Then it creates a user and prints the username and phone number.

Django
from django.contrib.auth.models import AbstractUser
from django.db import models

class CustomUser(AbstractUser):
    phone_number = models.CharField(max_length=15, blank=True, null=True)

# Usage example (in Django shell or views):
# Create a new user with phone number
new_user = CustomUser.objects.create_user(username='alice', password='password123', phone_number='+123456789')
print(f"Username: {new_user.username}")
print(f"Phone: {new_user.phone_number}")
OutputSuccess
Important Notes

Changing AUTH_USER_MODEL after migrations is hard; set it before your first migration.

Time complexity is not affected by adding fields; it's about database queries.

Common mistake: forgetting to update AUTH_USER_MODEL in settings.py.

Summary

Custom user models let you add fields or change user behavior.

AbstractUser is a good base to keep Django's default features.

Always set AUTH_USER_MODEL before creating migrations.

Practice

(1/5)
1. What is the main reason to create a custom user model by extending AbstractUser in Django?
easy
A. To add extra fields or change user behavior while keeping Django's default features
B. To remove all default user features and start from scratch
C. To automatically create admin users without configuration
D. To avoid using migrations in the project

Solution

  1. Step 1: Understand AbstractUser purpose

    AbstractUser provides Django's default user fields and behavior as a base class.
  2. Step 2: Reason for extending AbstractUser

    Extending it allows adding custom fields or changing behavior without losing built-in features.
  3. Final Answer:

    To add extra fields or change user behavior while keeping Django's default features -> Option A
  4. Quick Check:

    Custom user model = Extend AbstractUser for extra fields [OK]
Hint: AbstractUser keeps defaults; extend it to add fields [OK]
Common Mistakes:
  • Thinking AbstractUser removes default features
  • Believing custom user models skip migrations
  • Assuming admin users are auto-created
2. Which of the following is the correct way to declare a custom user model by extending AbstractUser in Django?
easy
A. class CustomUser(AbstractBaseUser):\n pass
B. class CustomUser(User):\n pass
C. class CustomUser(models.Model):\n pass
D. class CustomUser(AbstractUser):\n pass

Solution

  1. Step 1: Identify correct base class

    The question asks for extending AbstractUser, so the class must inherit from it.
  2. Step 2: Check syntax correctness

    class CustomUser(AbstractUser):\n pass correctly defines class CustomUser(AbstractUser): pass which is valid syntax.
  3. Final Answer:

    class CustomUser(AbstractUser):\n pass -> Option D
  4. Quick Check:

    Extend AbstractUser with class CustomUser(AbstractUser) [OK]
Hint: Use AbstractUser as base class for custom user model [OK]
Common Mistakes:
  • Using User instead of AbstractUser as base
  • Inheriting directly from models.Model without user features
  • Confusing AbstractBaseUser with AbstractUser
3. Given this custom user model:
from django.contrib.auth.models import AbstractUser
from django.db import models

class CustomUser(AbstractUser):
    age = models.PositiveIntegerField(null=True, blank=True)

# settings.py
AUTH_USER_MODEL = 'myapp.CustomUser'

What will happen if you try to create a user without specifying age?
medium
A. User creation fails due to missing age field
B. User is created successfully with age set to None
C. User is created but age defaults to 0
D. Error because age is required

Solution

  1. Step 1: Analyze age field definition

    Age is defined as PositiveIntegerField with null=True and blank=True, so it is optional.
  2. Step 2: Understand user creation behavior

    Since age is optional, creating a user without it sets age to None (null in database).
  3. Final Answer:

    User is created successfully with age set to None -> Option B
  4. Quick Check:

    Optional field with null=True allows missing value [OK]
Hint: null=True means field can be empty on creation [OK]
Common Mistakes:
  • Assuming blank=True means field is required
  • Thinking missing fields default to 0 automatically
  • Confusing null=True with default values
4. You created a custom user model extending AbstractUser and set AUTH_USER_MODEL in settings. After running migrations, you get an error about conflicting user models. What is the most likely cause?
medium
A. You set AUTH_USER_MODEL after initial migrations were created
B. You forgot to import AbstractUser in your model
C. You did not define a primary key in your custom user model
D. You used AbstractBaseUser instead of AbstractUser

Solution

  1. Step 1: Understand migration timing

    If AUTH_USER_MODEL is set after initial migrations, Django creates default user tables causing conflicts.
  2. Step 2: Identify cause of conflict error

    The conflict arises because two user models exist: default and custom, due to late setting of AUTH_USER_MODEL.
  3. Final Answer:

    You set AUTH_USER_MODEL after initial migrations were created -> Option A
  4. Quick Check:

    Set AUTH_USER_MODEL before first migration [OK]
Hint: Set AUTH_USER_MODEL before first migration to avoid conflicts [OK]
Common Mistakes:
  • Ignoring migration order importance
  • Assuming import errors cause this conflict
  • Confusing AbstractUser with AbstractBaseUser issues
5. You want to add a bio text field to your custom user model extending AbstractUser. You also want to display this bio in Django admin user list view. Which steps should you follow?
hard
A. Add bio field to model, override save() to print bio
B. Add bio field to model, no admin changes needed
C. Add bio field to model, register custom user admin with list_display including 'bio'
D. Add bio field to model, create a new admin site

Solution

  1. Step 1: Add bio field to custom user model

    Define bio = models.TextField(blank=True, null=True) in your model to store user bios.
  2. Step 2: Customize admin to show bio

    Register your custom user model admin and set list_display = ('username', 'email', 'bio') to show bio in list view.
  3. Final Answer:

    Add bio field to model, register custom user admin with list_display including 'bio' -> Option C
  4. Quick Check:

    Model field + admin list_display shows field [OK]
Hint: Add field + update admin list_display to show it [OK]
Common Mistakes:
  • Forgetting to update admin list_display
  • Overriding save() unnecessarily
  • Creating new admin site instead of customizing existing