# Topic covered
* Django default User Model
* Custom User Model
    * AbstractUser vs AbstractBaseUser
* Validating objects
    * full_clean()
    * Model.clean_fields()
    * Model.clean()
    * Model.validate_unique()

https://openclassrooms.com/en/courses/7107341-intermediate-django/7262933-customize-the-user-model

Django default User Model

By convention, data on an individual user is stored in a model called User. Django provides a default User model. This model has many special methods and features, particularly concerning authentication and permissions, that make it seamlessly integrate into the Django framework.

# from django.contrib.auth.models import User

• username, first_name, last_name, email
• password - this is stored as a hash in the database. Never store raw passwords.
• is_staff - a boolean; dictates whether a user can log in to the Django admin site.
• is_active - a boolean; it is considered Django best practice to mark users as inactive by setting this attribute toFalse instead of deleting them.
• is_superuser - a boolean; superusers are automatically granted all permissions, such as access to the admin site.

superuser - The most powerful user with permissions to create, read, update and delete data in the Django admin, which includes model records and other users.

staff - A user marked as staff can access the Django admin. But permissions to create, read, update and delete data in the Django admin must be given explicitly to a user.

active - All users are marked as active if they’re in good standing. Users marked as inactive aren't able to authenticate themselves. A common state if there’s a pending post-registration step (e.g. confirm email) or a user is banned, and you don’t want to delete his data.

Custom User Model

If the fields in default User model don't fit - we can create own custom user model.

Even if you think that the default User model is good enough, you should always implement a custom User model in your project, even if it is identical to the default one.

This is because it is difficult and complicated to migrate to a custom User model after your Django site has been set up and your initial migrations have been run. It requires lots of tricky migrations and an in-depth understanding of SQL. Plans change, and clients alter specifications. Save yourself a headache and set up a custom User model at the start of your project.

Two ways to create by using - AbstractUser or AbstractBaseUser

In Django, AbstractUser and AbstractBaseUser are two classes provided for customizing the default User model. While both serve to allow customization, they are used in different scenarios and provide varying levels of control

AbstractUser

AbstractUser is a subclass of AbstractBaseUser and includes all the default fields and functionality of Django’s built-in User model.

When to Use

• You want to extend or modify the default user model but retain its basic structure (fields like username, email, is_staff, etc.).
• You only need to add custom fields or override a few default methods.

Features

• Pre-integrated with Django’s authentication system, admin site, and forms.
• Provides a ready-to-use user model with minimal customization.
• Allows you to add new fields by subclassing it.

Default Fields

• username, email
• first_name, last_name
• is_staff, is_active, is_superuser
• last_login, date_joined

Example

Add new fields by subclassing AbstractUser.

from django.contrib.auth.models import AbstractUser

class CustomUser(AbstractUser):
    account_number =  CharField(max_length=10, unique=True)
    

# settings.py
AUTH_USER_MODEL = 'myapp.CustomUser'

Want to use an email instead of username to log in

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

class User(AbstractUser):
    email = models.EmailField(unique=True)
    username = None

    USERNAME_FIELD = 'email'

AbstractBaseUser

AbstractBaseUser is a more low-level and flexible class that provides only the core authentication functionality (password management and authentication-related fields like last_login).

When to Use

• You need complete control over the user model.
• You want to define your own fields and methods from scratch.
• You want to customize the authentication mechanism, such as using email instead of username for login.
• AbstractBaseUser is used if you don't want to use every field provided by the default User class.

Features

• Does not include fields like username, email, is_staff, etc.
• Requires you to define your own:
  • User fields (like email, username, etc.)
  • Methods like get_full_name() and get_short_name().
  • A custom manager for user creation (objects).
• Requires implementing permissions management if you plan to use the admin site.

Default Fields

• password
• last_login